I think that having sensitive data (whether it is the password, or derived key, etc) in memory is not something that most systems deal with.
That being said, here are several possible mitigation methods for protecting private data in-memory. This could apply to a variety of subjects, Server, Mobile or Desktop. The principals are the same. I'm also not sure which attack vectors you are most interested in. (virus, physical attacks)
An obvious first step would be to disable swap which is a feature that takes less used 'pages' of memory and writes them to a space on the hard disk. It would be fragmented, but quite possible for the attacker to get data with this method.
It is possible that some OSes provide a means to store specially marked memory that is forbidden from being stored in swap. I've never researched it though, and I am sure it is more complex than your typical runtime variable. If you did it this way, you would no longer need to disable swap on the whole machine taking the performance hit associated.
@Stephane comments that Windows has an option called CryptProtectMemory which encrypts the memory. I think this is clever as that way only the key would have to be forbidden from swap, instead of each individual piece of sensitive information.
As for the Memory itself (swapped or not), if you are logged in as root or as the same user account the process is running under, there is a means to dump all memory for that given process. Many of the high-level programming languages provide this functionality internally with the same user account conditions.
- Android solves this problem by providing each app with their own user account in the OS, which gives many additional benefits.
- Server environments often have services segregated into alternate user accounts to help contain potential breaches, both from a memory and from a file-system storage perspective. (never run a public-facing service as root!)
- In a traditional desktop environment, there's not much you could do to secure processes running in the same user account.
The last possibility would be a special hardware module (either to store the data, or an encryption key for the data) which is separated from the main operating system. I would suggest taking a brief look at Trusted Execution Environment (TEE) and/or Secure Element (SE). See Android Keystore System.
There is also the more extreme method of using a completely separate (small) computer, i.e. Raspberry PI.
Specifically to your example of a Master Password, you could of course not store the overall master password, but just final password that was extracted from the store. This way the user has to re-enter the Master Password when visiting a new site.