If you're using the user password to decrypt the encryption key, why don't you simply derive the encryption key dinamically from the password each time the user logs in? I'm thinking of an algorithm that, given a string (the user's password), constructs a given key. Something like SHA-*, but more tailored to your use case.
In this way you wouldn't need to store the encryption key anywhere, as it's dinamically generated on demand.
As per the criticism on the user losing the password, I disagree with most comments. I think that if it's made very clear to the user why there is no recovery procedure, it can be a plus, but is has to be properly explained.
Anyways, to solve this, I'll throw my 2 cents. The recovery process could be done woth a local-based (no server) Q&A process. For example, when the user creates the password it is asked to provide three security questions, and the corresponding answers. Then the questions are stored locally and the answers are used to create an encryption key to encrypt the password, which is then stored locally. If the user forgets the password, it is asked the three questions and if the answers are correct the password is correctly displayed.
Now I know that many will tell me that storing the password in a database, even though encrypted, is a bad idea. But I'll respond that we are talking in this case of storing the encrypted password only locally. This means that to stole the password one would need phisical acces to the machine, and then it would need to crack the encryption. Which at this point makes this system much more secure than most SAAS that, while encrypting very well passwords server side, do allow (for obvious reasons) the user to stay logged in. So anyone with access to the machine can access all data without further work.