Connect through two VPN clients
A typical VPN client works like this: it connects to the server, and then it instructs the operating system to give him all packets which are to be sent to any address in a given set. For instance, let's assume that the VPN client advertises that it should handle all packets meant for 10.0.0.0/8 (i.e. all IP addresses which start with "10"). When the OS sees a packet which should go to address "u.v.w.x", it checks whether "u" is "10"; if yes, then it gives the packet to the VPN, which does its magic with it and forwards it, under heavy encryption/MAC/whatever to the server; otherwise, the packet is emitted "to the Internet" as the OS would have done without the VPN client.
Details on how this system is implemented depend on the VPN implementation (e.g. it may declare specific "routes"; or it could intercept all outgoing packets with firewalling rules and redirect the packets it is interested in;...).
If you have two VPN clients and their "advertised sets of addresses" do not overlap, then chances are that they will live together nicely at the IP level: each will grab the packets for its own virtual network, leaving the other packets untouched. However, they might also fight for the "interception resources" which may result in the first VPN client to be wholly deactivated.
On the other hand, if both VPN advertise overlapping sets of addresses, then trouble is pretty much guaranteed. If you are lucky, the second VPN will refuse to run with an explicit message. Otherwise, one of the clients may take precedence, possibly intermittently, and things will be weird and confusing. Possibly, one VPN server will receive the packets which were due for the other VPN, thus incurring a severe data leak.
There will be trouble with DNS. Applications and humans do not want to deal with IP addresses but with host names. The DNS converts host names to IP addresses. A VPN being a "virtual private network", it uses names which are not visible to the worldwide, Internet DNS. Therefore, a VPN client will not only intercept IP packets, but also the name resolution system, and redirect some (if not all) of name resolution requests to a dedicated DNS server on the VPN.
Your two VPN clients will compete for that redirection. Things might just work well if the clients manage to redirect requests for just some domains. But chances are that hijinks will ensue. Some names for one VPN will probably cease to be convertible to IP addresses, resulting in reduced functionality. Possibly, one VPN will receive name resolutions for the other VPN, so not only is the functionality broken (because the DNS in one VPN will not know what to do with names from the other VPN) but some private data leaks from one VPN to another (host names are rarely very sensitive, but that's still a leakage).
In this last situation, the VPN which receives name resolution requests for private names of the other VPN is in ideal position to respond with forged DNS answers and redirect all traffic from the other VPN to itself.
So don't do that. Running several VPN clients concurrently is a source of trouble, hard-to-diagnose failures and potential data leaks.
To avoid issues with multiple VPN, you should endeavour to use more "controlled" forms of VPN. For instance, a SOCKS proxy with ssh. This would allow you to run one Web browser which redirect all its traffic to another host (the "VPN server") while leaving the rest of the machine (and, crucially, other browser instances) unaltered. See this answer for instance. Some purists say that such proxying is not a VPN, but for many practical purposes (anything which is Web-based, really), this is functionally equivalent. See also the alternative with port-based tunnels.
I used to do that a lot at one time (a dozen or so port-based tunnels, and also SOCKS proxying, and it was all working well). The SOCKS solution works well for name resolution too: the name resolutions requests from the Web browser will go through the tunnel, to be resolved on the other side (i.e. in the VPN), without touching the local DNS configuration. Port-based tunnels require a static local name declaration.