The solution you describe is, actually, hashing.
Consider the hash function MD5. It works by starting with a conventional fixed value (the "IV") of length 128 bits. Then, for each 512-bit block of input data, a compression function is computed, which takes as input the current 128-bit state and the 512-bit message block, and outputs the next 128-bit state. If you look at how the MD5 compression function works, you will see that it is similar to a block cipher (a generalized Feistel scheme with four sub-words) where the 512-bit message block is used as the key. So MD5 really operates as you describe it: encrypt a fixed value, with the password as key. If the fixed value is user-specific, then it is a kind of "salt" (and that's good for password hashing).
So your question is: can't we build a hash function out of a block cipher ? And the answer is: yes, but it requires some care. A typical block cipher such as the AES is designed for encryption and its security has been analyzed in that context. When you turn a block cipher into a hash function as described above, you are relying on the block cipher being robust in ways which have not been thoroughly explored -- you need the cipher to be resistant to related-key attacks, which are a non-issue as far as encryption is concerned, but can be deadly to a hash function. For instance, the AES is known to be somewhat weak with regards to related keys, so using it "as is" in a hash function is not necessarily a good idea.
Whirlpool and Skein are two hash functions which reuse a block cipher -- in both case, a specialized block cipher, optimized for resistance in that specific situation.
Regardless of the details of hash function design, any password storage system has a big, glaring weakness, which is that it stores the password or, at least, a password verification token (something which can be used to decide whether a given password is correct or not). Passwords come from the brains of human beings; they cannot be strong. It is highly possible to enumerate most potential passwords.
It is unavoidable that a server which verifies passwords contains enough information to, say, verify passwords. Therefore, if an attacker can get a dump of the server's disk, then he also gain that power, and can try passwords "at home". This is an offline dictionary attack. The only known defence (arguably, the only possible defence) is to make each password verification inherently slow, preferably in a configurable way. THAT is the point of bcrypt: the password hashing uses millions of elementary operations, without any known shortcut, so that the attacker will have to pay a high price for each try.
A homemade hash function, built from a block cipher, will fail at that -- unless you define it to use not one encryption, but one million successive encryptions. It would still be homemade (that's very bad in cryptography; don't trust homemade designs), but at least it would not be as awfully weak with regards to dictionary attacks.