A bit more digging and I realize that this isn't truly a bug in IE, but in an ActiveX component that ships with IE.
I set all of my ActiveX, signed or not, approved or not, to prompt and this fixes that problem
[ davidkearns.com - Scary: my little slice of opinion and triviality ]
This means you simply need to disallow the use of that one component. If you have XP SP2, you're in luck, since ActiveX components are a type of add-on, and you can now disallow add-ons. Go to Tools/Manage Add-ons... Change the “Show:” to “Add-ons that have been used by Internet Explorer” and find the “DHTML Edit Control Safe for Scripting for IE5” and set it to “Disable”. This is bound to break something somewhere, but better that then having your financial info snagged or something.
Interesting thing to note, though. After the above jerry rigging my IE would no long fall for the test, however my SlimBrowser still happily runs the add-on. Perhaps a reboot or something is required due to some sort of caching of background process or something, but if not this exploit is still obvious due to the brand new IE window that SlimBrowser spawns via the test (and thus alerts me to the odd behavior, since SlimBrowser usually doesn't do that).
Update: After a reboot and an upgrade to SlimBrowser 4.03.007 it still falls for this exploit. One odd bit about the exploit is that although the wee little yellow lock appears, which should indicate that the page has been encrypted, double-clicking on the lock displays a dialog that indicates “This type of document does not have a security certificate” which certainly sounds like an error exists in IE as well.