I'm assuming you are talking about HTTP traffic here (there's a big difference between stateful and stateless protocols).
The problem is that to get best performance you want SSL session resumption to work - which favours a sticky session approach - but if your sessions are too sticky, then you won't have any failover. The big expensive boxes from f5, Cisco et al can cope with that, but its difficult to do across commodity boxes running (for instance) stunnel.
I still think that the best solution to most load balancing problems is round-robin DNS - where failure detection is on the only place that a failure can be reliably detected (the client) and this is where the failover is implemented - it provides for server affinity but still allows failover of requests (note that it does not support resumption of requests - but I've yet to come across anything which supports this for HTTP).
One other thing to bear in mind is that Microsoft's keep-alive support for HTTP over SSL is different from that implemented by everyone else. This is not just an openSSL thing - other vendors give the same advice. Given the additional overheads in SSL negotiation and the huge pay-off using keep-alives for HTTP traffic it may be worth considering using MS-ISA for SSL termination - although I'm guessing that it is possible to configure the software as such and I've never been impressed by the products scalability/reliability. So if I had lots of money to spend then I'd probably look at MSISA for SSL termination but not using Microsoft's clustering software and moving the failover elsewhere (e.g. to the client!).
For a cheap solution, terminate the SSL on the webserver boxes with round-robin DNS. Add lots of webservers. Optionally use a cryptographic accelerator card (not an SSL capable network card) in the webserver for additional oomph.
For a very fast solution - (possibly) multiple MSISA nodes addressed via round-robin DNS, talking to a LVS cluster of webservers.