This might not be possible to do in a general way, let me explain why.
If you use any library, pattern, or whatnot, that uses "convention over configuration", the only way to 100% determine whether you can remove a class is to execute the code, and you're going to have to ensure that you execute all code paths for all scenarios, something which in most cases isn't possible.
For instance, if any of the code uses reflection to figure out which classes are available, whether you can safely remove a class that that piece of reflection code would find would depend on what was done with the class once found.
You could for instance end up removing classes from an ASP.NET MVC 4 assembly, because it looks like the View classes aren't used, but they are found and used through reflection, and not explicitly in your code.
My tip would be to either disregard this, after all, 2MB isn't all that much, or I would split up the larger project into smaller ones by topic. This way a project would only reference the parts of your class library that it needs.