I'm assuming you simply can't increase the raw bandwidth of your site...
You may see benefit from not using compression on the host.
If you use something like a wan optimizer, it will be able to optimize the transfer much better if you don't compress the file before you send it, ie you do exactly what you're doing but remove the bzip2 from the pipe. After a couple runs of your backup, the wan optimizer will have cached a very large fraction of the stuff it sees in the transfer and you'll see huge improvements in transfer speeds.
If you're on a limited budge, you may be able to see a similar improvement by using rsync and rsyncing the uncompressed snapshot, ie:
zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 > /path/to/snapshotdir/snapshotfile
rsync /path/to/snapshotdir/snapshotfile offsite-backup:/remote/path/to/snapshotfile
ssh offsite-backup 'zfs recv -F tank/vm < /remote/path/to/snapshotfile'
This would be faster because rsync would only transfer the differences between yesterday's snapshot and today's. Depending on how the snapshotting process works, there may still be lots of redundancy between the two even if they're not really the same file at all.
The wan optimizer is by far a more likely way to fix this problem (well, metro ethernet is the most likely way to solve this problem, but we'll leave that off the table). The rsync is just a wild shot in the dark that's worth testing (locally; rsync will tell you how much time it saved over a straight copy) on your local data before writing the big check for fiber or a riverbed install.