As far as I understand the C# language, I don't think this code is safe to use.
While it will remove the item from memory, it does not remove any pointers to it, which could cause null point exceptions.
This is because the way the content manager works, any time a part of the code wants to load the asset, (say for example, grass in a game, an object containing location and texture) it checks to see if it already has the asset. If yes, it just returns the pointer to the same asset. (pointer, pass by reference, asset is a generic, generics are classes, classes are only ever handled by reference). So say, I have lots of grass objects, and I go into a house, so I unload a scene, we have to make sure at no point does the grass object act on or off of the texture after it gets loaded, every object owning a pointer to the asset must remove that connection or the parent object must be deleted (disconnected and forced garbage collected, maybe even defragged by a second forced collection), or by some other trick make sure the texture is not used ever again, so that you can then unload the asset safely knowing that no other objects have fantom memories of the asset. Generally, the idea is not idiot-proof, that doesn't make the code bad, but it does make it an issue.
Basically, you have to be smart and safe with the unloading.
You could modify the content manager such that it keeps track of all connections, and removes them when unloading, but that does not help with if an object wants to try to access the asset again for some reason in the code, unloading is generally not safe.
It seems the best work around is as poohshoes suggested
or better said
'Sceen' being something akin to unity's "scene" system
this is kinda safe. But that still requires users to design scene so that all the objects are destroyed as well. The only issue with this, however, is now you have to reload all assets, none carry over. A bit more load time at the risk of memory conservation. though I would also garbage-collect and defragment at this time as well.