Your average connections per second isn't the important thing; it's the peak you've got to be worried about. For that, you need better statistics on what your load patterns will look like. If you don't have that, I usually use a 4:1 peak/average ratio across the 24-hour average (so for you, you're looking at 1.6 / 3 * 4` -- 3 to get to the 24 hour average, 4 to get the peak from the average -- a bit over two connections per second at peak).
This ratio, by the way, simply comes from my experience with sites with geographically localised userbases (like you suggest). I've got other ratios for global userbases and "known peaky" sites. If you take the worst case, a really peaky site, I use a ratio of 10:1, so you're still only looking at a bit over five connections per second.
Like Andrew says, at that sort of volume you shouldn't even be breaking a sweat on one machine. I've got a site that does handles several hundred HTTP(S) connections per second per machine (a dynamic-heavy site, with a lot of SSL connections) -- obviously that's going to vary a lot by your codebase, but if you need to load balance five SSL connections per second, something is very, very wrong.
Personally, I don't like SSL accelerated load balancers, as in my experience they just make for a whole new bottleneck -- when your site gets popular enough, the SSL accelerator won't be able to keep up (and upgrading those things gets expensive). I prefer a simple TCP load balancer, where I can simply scale out my backends as they reach capacity (whether it's because of SSL connections or just processing requests).