Sorry, have been away for a while ...
Certainly, the concept of keeping *everything* on the SSL connection is sound, and by far the easiest solution.
Looking at the approach that you then go on to outline, I'm not sure that it will work, or at least, it's very prone to breaking, or missing something - including some of these problems:
Firstly, you'll also need to catch the response to a (successfull) wp-login - this is where the login cookie is first returned to the user, and thus must also be sent over SSL.
Secondly, you'd need to check/modify the domain setting for the cookie to ensure that the client browser knows to only send it for requests to https://some.wordpress-site.org, and not the http equivalent - otherwise, it can still be intercepted easily as before.
Finally, because you're no longer sending the cookie to the insecure version of the site, it doesnt know that the user is logged in, and so non-admin facilities are unavailable (including posting comments, editting, etc).
So, as I said, it's much simpler to just deploy wordpress on an SSL-only host, if security is that important.
A simple, additional safeguard is to have a second user account, that has the minimum security level for day-to-day tasks, and only use the admin login where absolutely necessary.
I like the idea of the Apache authentication patch/plugin you mention, I shall have to look into this later. The obvious benefit of this, to me, is that it can share usernames and passwords (and possibly even provide single-sign on behaviour) with existing systems. As you say, it doesnt change the fundamental problem of security, but provides other benefits instead.