In principle you may be able to defend against passive attacks.  But in practice it's non-trivial and not a great solution.

In principle, you can write your own encryption code in Javascript to encrypt everything on the client-side (in Javascript).  The very first thing you run into is that this has poor performance, because crypto in Javascript is substantially slower than the browser's native crypto.  The natural reaction is to suggest encrypting just the most sensitive data, e.g., just the user's passwords.  However, this is very difficult to get right and has many subtle pitfalls:

1. If you're not encrypting the cookies, you're vulnerable to session hijacking, and you've gained nothing.  And it's not easy to encrypt the cookies or other HTTP headers from Javascript.  So you'll probably be forced to end up inventing your own user authentication method and use something other than cookies (something homebrew) for session management, which is a bunch of work and easy to get wrong.

2. If you encrypt only the password, then you may be vulnerable to CSRF attacks.  An eavesdropper can still see all the page content, and in particular, if CSRF tokens are included in the link, then the eavesdropper can see all of the CSRF tokens and mount a CSRF attack.  It's possible to defend against this with sufficient effort, but it requires still more work on both the client and the server, and is tricky to get right.

3. If users can log into your site using their Facebook account, since you don't control Facebook, you can't prevent an eavesdropper from stealing their Facebook account and then logging into your site.  

4. You're still vulnerable to man-in-the-middle attacks (active attacks) that modify the page content.  It would not be terribly technically difficult to modify Firesheep to use ARP hijacking, race attacks, or other methods to insert itself as a man-in-the-middle and modify all page content.  Then security is lost, since the attacker can insert malicious Javascript that acts as a keylogger or otherwise steals the authentication credentials.

5. You have to be careful that you don't lose the benefit of caching.

Now I'm not saying it's impossible.  It almost certainly isn't.  It is almost certainly possible to build a web site and a solution that prevents most passive attacks.  But it will be complex and non-trivial.  That means you'll need considerable security expertise to build it, and there's still a non-trivial chance you screw something up.  It also means that the result will be expensive.  And the security is inherently limited -- any scheme will be only a partial solution/mitigation -- so the value is limited.  I don't think it's a good tradeoff.

If you want to read about state-of-the-art attempts to defend against eavesdropping without use of SSL, here's a great resource for you:

* Ben Adida's SessionLock and http://benlog.com/articles/2010/10/25/keep-your-hands-off-my-session-cookies/

I'd also like to share with you some resources on making SSL perform well:

* EFF's guide on deploying SSL: https://www.eff.org/pages/how-deploy-https-correctly
* Tips from Google on making SSL fast: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
* Ivan Ristic's top 10 SSL deployment mistakes: http://ssl.entrust.net/blog/?p=155
* Ben Adida's skepticism, and some replies from users: http://benlog.com/articles/2010/10/26/ok-lets-work-to-make-ssl-easier-for-everyone/

SSL isn't free -- but also keep in mind that people sometimes assume the performance impact of SSL will be worse than it actually is.