bcrypt is not meant for this type of client-side hashing
A key property of bcrypt is that, when run two independent times with the same plaintext, most implementations will produce different hashes. This is due to the use of a salt, which is designed to make it difficult to see if two different users have the same password.
In contrast, login forms need to receive the same data every time. After all, how else would you verify that the password the user typed today is the same as what they typed yesterday?
So, you have an algorithm designed to produce different data each time, and you're feeding it into an application that needs to verify the data is the same each time. That's probably an indication that the algorithm is not being used as intended.
What you should ideally be doing is using bcrypt to hash passwords on the server. That's what bcrypt was designed for: protecting user passwords during times when the plaintext is not in memory, which is by far the most common state (e.g., DB dumps would reveal only the hashed password, not the plaintext, if implemented correctly).
I personally see some value in client-side hashing as well, because it does help protect against attackers who can sniff the traffic (or who have server access). However, I don't know of a way to make client-side hashing as secure as server-side bcrypt - which is why you should still be using server-side bcrypt.
If you must use bcrypt client-side, use a static salt
If you're GOING to use bcrypt for client-side hashing of a login form, and you want it to be a drop-in replacement for MD5, you need to use a static salt. Especially if you're passing it through SHA1, because that would mangle the bcrypt salt as well as the hashed data itself.
This does break several design assumptions of bcrypt (such as always using a random salt), of course.
I'd personally recommend using the username as a salt (so that it's difficult to tell whether two different users have the same password); however, I don't know of any research that's been done on salting in this context.
AES (or any symmetric cipher) is useless here, too
Keep in mind that AES is a symmetric algorithm, meaning that you need the same key to decrypt and to encrypt data.
What you should be using instead is public key cryptography, such as PGP or HTTPS (technically, HTTPS uses a hybrid approach). Seriously, just use HTTPS, unless your organization refuses to let you have an SSL certificate, for some reason. Keep in mind that PGP won't really protect against active MITM attacks, but it would at least protect against eavesdropping.