All you would have to do is look at the current nat translation table on the nat device to see what port the IP maps to. For instance on a Cisco router 192.168.1.82 connecting to google via pat to the public ip of 12.12.12.12:
router1#show ip nat trans
tcp 12.12.12.12:33949 192.168.1.82:33949 66.249.80.104:80 66.249.80.104:80
Update:
I think I understand now. I don't know of any implementation of this, but I don't see why it wouldn't work. You could in theory map each internal ip to a different port range. Since overload translates the internal ip/tcp src port combo to an external ip/tcp source port, you could assign certain external source port ranges for each internal IP (previous could also be udp ports). For example:
32000-33999 public ip's tcp/udp src ports on ip 12.12.12.12. will be used for 192.168.1.2
34000-35999 public tcp/udp ports on ip 12.12.12.12. will be used for 192.168.1.3
The problem with overloading is that you start to limit the possible connections, because instead of a normal 4 item combination to identify a session (source ip, source port, destination ip, destination port), you are limited it to 3. So when you restrict one of these even more by limit the port range you limit the number of sessions. So in my above example, you ip 192.168.1.2 could only have up to 2000 connections to any specific public ip. I also don't know if a overload code works like this, as it might use just the source port to translate instead of the source port / source ip (talking about return packets here) to be faster.
Maybe you could get around that with sequence number trickery, but I think that would take a lot of tcp reworking and open up security holes. If this has been implemented I will be a little surprised. NAT is kind of a hack I think to help with ip shortage. PAT/Overload is kind of a further hack of this, making it a hack of a hack. To start identifying sessions by sequence numbers would then be a hack of a hack of hack. At that point, it is really time IPv6 already :-)