Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Are there any security objections against keeping the transformed master key in memory?
The only thing affected by this is that the key for the AES transformations stays constant.
Though I don't see how this could lower the security.
I implemented this in KeePassX. As the time needed to save the database
is dramatically reduced, I could add an option to automatically save the database
after every change.
The idea behind the protection against dictionary and guessing attacks  is the following: we have a key provided by the user and transform it to form a different key, which is then used by KeePass in the encryption process. This transformation takes time (encrypting it repeatedly for a given time span) and an attacker has to do this transformation for each key and each database he tries.
If the encryption key for the master key AES transformations is constant, you can precompute a plain text <-> result key table based on a dictionary. A company (providing password recovery) could for example compute such a table and then apply it to *all* databases instead of only a specific one (as the table would not be dependent on a key/seed anymore). This renders the whole key transformation process almost completely useless.
For sure there are other cryptographic layers. Even if you remove the protection against dictionary attacks KeePass would still be pretty secure (like any other encryption product without this protection). Anyway, I want to provide KeePass users the strongest security possible, and will therefore not accept this change.
Please let me know whether you want to keep your modification in KeePassX. If so, I will write a notice in the security documentation that KeePassX doesn't have this feature (anymore).
If your only goal is to speed up the file saving process, you could choose a random transformation key/seed and pre-compute a transformed key in the background (thread), such that you have one transformed key ready when the user wants to save.
The transformation key is still random. The only thing that changes is, that it stays constant per database.
So it is not possible to compute a rainbow table.
To clarify this a bit more:
Whenever the user creates a database/changes the key/changes the number of key transformation rounds/changes the encryption algorithm, the transformation key is randomly generated.
On every other change the transformation key stays the same.
I don't think that security is improved, when you change the transformation key on every database save. You just replace a random key by another random key.
If you do it like this (which is different from what you suggested in your first post), I agree that pre-computing a table is not possible. Although I currently don't see a simple attack on your scheme either, using a new random transformation key each time can only be more secure.
I don't see why the risk of opening KeePass up to advanced cryptographic attacks should be taken, just for a minor speed optimization, which can even be achieved in a different and secure way (background thread).
I wonder if placing the computing load (transformations) only at the points where it positively affects security might be a net security win. If one reduces the transformation time delay for the save operations, users might be willing to use more/longer transformations at database creation, startup & unlocking thereby increasing resistance to dictionary attacks.
As a lay user, the save time doesn't bother me - and I run off a slow USB stick.