I don't think you can say the pane technically has a PID, ever. The process in the pane has a PID. The pane acts as a pseudo-terminal. You can start a pane with, say, an instance of top. It will run until you close it and and then the pane will close (by default anyway, don't know if this behavior is changeable). The top instance will have an associated PID while it runs.
Edit: When starting a new job, (example: split-window -h "top") tmux spawns top in the new pane and the process of top is pane_pid. When starting multiple jobs in a new pane (e.g., something like split-window -h "top; tail -F /var/log/maillog"), tmux seems to spawn a non-interactive shell for job control. That shell gets apparently gets pane_pid, rather than the first process ("top" in the second example).
It appears that by design the pane only stays open as long as the initial process that started in it is running (though at least in theory the inside process could survive the closing of the pane as a zombie process). That process can spawn new processes, of course. So I guess you can say there is a "magic process" in a pane that, if killed, will cause the pane to close, but the pane itself still technically does not have a PID. This makes sense because there is no more input or output going to the pseudo-terminal.
BTW, this all seems analogous to normal Linux terminal behavior. When you first log into your terminal, you get a bash (or other shell you specify in your user file) process that was spawned by the login process. If you log into tty1 and tty2 at the same time, you will get a shell for each. Run ps -u and you can see the shell process running and what terminal it's running (tty1, tty2, etc.) on. If you kill the shell process in, say, tty2, you will be logged out of tty2. But tty2 stays open because the OS spawned a getty to keep that open.