I used to deploy WAN acceleration devices for a hardware vendor about 6 years ago. Not much has really changed since then except I won't make hardware recommendations because of consolidation and changing product lines.
All of these devices use some combination of compression and caching to reduce the overall traffic to be transmitted, TCP pre ack'ing to reduce the effects of bandwidth delay product (this is the TCP window effect that you alluded to above) and ganging of undersized packets to insure that packets traversing the links are as full as possible reducing the effect of overhead. The various vendors will throw in their own patented technologies as well, but they mostly boil down to different flavors of these.
While caching is a major help, just the pre-ack'ing of packets over a satellite link will go a long way to making them usable, so that even if your data isn't cacheable for whatever reason (encrypted, compressed, zipped, always changing drastically, etc) if you have a slow enough RTT the pre-ack'ing will partially eliminate the bandwidth delay product and help you get closer to your nominal bandwidth.
Since the whole goal is to drive up network efficiency and allow higher utilization of your bandwidth, it's very important that underlying network problems that may pop up with high utilization are fixed before deploying a solution. If you have duplex mismatches or are running on half-duplex connections you'll often find that performance is worse than before you deployed wan optimization devices. Often I would find that customers didn't realize that they had some links that had auto-negotiated down to the lowest common denominator of 10 Mbps half duplex.
Many of these devices also offer Forward Error Correction (which your modems probably offer as well) which you can use to overcome some of the effect of packet loss on your links. This is important since the packet stuffing means that more than one LAN packet could be lost for each WAN packet that gets lost and because of the pre-ack'ing those packets have already been acknowledged to the servers. Make sure that you know which devices in your path are performing FEC so that you don't create more overhead than necessary since this will of course reduce your effective throughput.
Speaking from experience, I saw customers without significant caching able to do 'acceptable' (mostly one way) video conferencing over a double satellite hope whose latency ranged from 900 ms to 2 seconds and might have 15-25% packet loss for extended periods. I wouldn't choose to use the resulting flow, but if that's what you have it'l work.