Accelerating VPN speed using multiple connections
Solution 1:
The number one way to increase the speed of the connection is to work with the internet service provider (ISP).
If the physical link is 1 Mbps symmetrical with 100 ms latency to the server, you will not be able to accelerate that beyond 1 Mbps and 100 ms latency via software.
You can add additional physical links to the connection increasing the overall bandwidth but additional links will not improve the latency. If latency needs to be improved you may need to find a different ISP.
Remember to look at both ends of the VPN connection; both the server-side and the client-side. You will not get the desired effect improving one-side if the bottleneck is already on the other-side.
Solution 2:
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.