This is a thoughtful comment, and I modded it up, but I can't resist saying this: your proposals basically suggest that we accept a lowest-common-denominator CRUD-app style login model and then bake it into the browser. We'd do that, freezing out any innovation or flexibility in login design, in order to... catch up to where we already are with forms.
There are definitely crappy login forms. So what? If an app can't clear the usability hurdle of getting people logged in, it's certainly not going to clear the (even harder) hurdles of "doing something useful for the user". In the end, many hundreds of millions of logins happen by all sorts of users every day. Lack of login-page standards doesn't seem like a real problem.
Your first point is excellent. But I'll raise you one. What if a login/logout cycle were made generic and could include several steps. The server says "401. You've got to login. I need a %username% and %password% and then I'm going to ask you one more thing." The browser asks the user for the username/password and then hits up the server with the response. If the authentication of u/p is successful it says "display this HTML doc and send me the result for final validation."
That sort of a model could work for both standard username/password setups and multiple-factor authentication. It's standard, flexible, predictable and you never have to search for it on an unfamiliar website.
As for your second point: there are plenty of websites that are difficult to login to even though they are used by millions. Try Citibank for one particularly bad example.
There are definitely crappy login forms. So what? If an app can't clear the usability hurdle of getting people logged in, it's certainly not going to clear the (even harder) hurdles of "doing something useful for the user". In the end, many hundreds of millions of logins happen by all sorts of users every day. Lack of login-page standards doesn't seem like a real problem.