And that's a bad idea why exactly?...
> Setting all login ID's to users' email addresses: This just removes more entropy from the login security process, since I now know that logins come from the set of valid email addresses.
Currently the username in my bank is a 9-digit number and they've got "over 30 million customers" I'm pretty sure I can guess a valid username in under 10 tries ;) Meanwhile, emails are almost an unlimited search space. The only thing that changes is that you're more likely to know who does the email belong to.
3. You might get some tiny fraction of additional security (through obscurity) by obfuscating people's logins, but this is ridiculous, unnecessary, and at great expense to the user experience when a decent password provides all the security you need.
Yes, email providers allow you to log in from their front page, but even then only from their gateway page. As a good example, www.yahoo.com does NOT have a login for their webmail client -- you have to click through to a separate screen. You only see the login if you go directly to mail.yahoo.com.
Most banks already offer an API, in the form of OFX. The security measures (like challenge questions) are already circumvented, and I've seen some really bad security flaws in OFX implementations when I last played around. e.g., inter-customer money transfers without requiring anything but the password, no auth lockout making brute-forcing possible, ability to crash the OFX gateway, &c.
(Yes, the newer OFX standards support multi-factor authentication, but I don't know of a single bank that uses the newer version.)
Also, most FIs hate the idea of financial aggregation, being worried about other companies cross-selling to their customers.
A sane REST API would be a wonderful step in the right direction, but I doubt it'll happen in the next ten years on a large-scale. Getting OFX to where it stands now took the combined market forces of Intuit and Microsoft many years, and didn't turn out well.
1. Log in from the home page: This would require the bank to serve its home page from https, including a redirect from http for every visitor, in case he or she wants to log in.
2. 4-digit passcodes: You're missing the key point about your ATM login -- it's only secure because it combines something you have (your ATM card) with something you know (your PIN). If everyone's login is a 4-digit number, then if I have a list of 10,000 users of your system, it would be trivial for me to compromise at least one account (not of my choosing) without even resorting to multiple login attempts.
3. Setting all login ID's to users' email addresses: This just removes more entropy from the login security process, since I now know that logins come from the set of valid email addresses. For any individual user, I now know their login with a high degree of certainty.
4. API: Do you think that banks really want to circumvent their security measures by allowing third parties to hold keys to the front door, even if the proverbial vault is locked?
All that said, I do agree that there are things that could be improved: making the login button front-and-center, so I don't have to guess where to find it; giving better choices for exporting financial data. But, you've got to realize that banks (online and offline) are prime targets for criminals, and that in some ways user experience has to take a back seat to protecting assets.