First off, check that your bottleneck is not the CPU required for encryption on your VPN. If your CPU is already maxed then no arrangement of spreading your traffic over multiple connections at the existing VPN server can help, though increasing the CPU resources available could.
A major limitation on the speed of any TCP connection is from the combination of Round Trip Time (aka ping) and Window size. See Wikipedia for more on that. Connections through your VPN may have a long round trip time, depending where your VPN is located. You may be able to improve things with some tuning of the TCP receive window size, but you might want to think first about the location of your VPN server. The effectiveness of increasing the TCP Window size is limited by the packet loss rate.
If you connect to your OpenVPN server over TCP, and it's a long way away, that link may be constrained by the RTT/Receive window size, and the limit imposed is on the total for all the traffic you put through that link. Connecting to OpenVPN over UDP might help there.
If you really want to have a go at spreading your traffic over multiple VPN links, you could look at this advanced routing guide, but it looks daunting. It gives an outline of how things work, and some of the commands necessary to put it in place, but being able to debug the setup would require quite a lot more than is presented. It seems likely that there should be a higher level tool to manage this, but I don't know it. I'd be interested to hear about such a thing.