Yes, you can NAT and/or PAT on the pix before you cross the IPSec tunnel that has one end terminated on it. The crypto map on the pix needs to refer to the NAT/PAT'ed address(es) as the source, not the true inside address.
What pix version are you running? I know that pix 6.3 can allow you to do policy nat, that is nat to one address for Internet access, and nat to another for the IPSec VPN connection. This may be of use for you, or not, depending upon how the other side expects to see you (another set of RFC 1918 addresses or the public address assigned for Inet).
I am assuming that the other side does not need to access resources on your network - is most cases each side needs to access resources on the other so that is why NAT 0 for vpn traffic is done - some protocols do not work well with nat, plus there can be some dns/name service issues too.
Here is an example of your net connecting to the remote net over ipsec using PAT:
On your pix:
nat (inside) 34 access-list remotenet_nat_01 0 0
global (outside) 34 a.b.c.d - where a.b.c.d is what the remote net sees you as
access-list remotenet_nat_01 permit ip y.y.y.y ym.ym.ym.ym r.r.r.r rm.rm.rm.rm - where y and ym are your network and net mask before nat/pat and r and rm is for the remote network
access-list cmap_acl permit ip host a.b.c.d r.r.r.r rm.rm.rm.rm - this is the acl that defines interesting traffic for ipsec and the other end needs a mirror image of this acl in their crypto map. Note that the source host a.b.c.d matches the global (outside) 34 statement as it is the nat/pat address that the other side expect you to be.
