Microsoft Fakes (formerly known as Moles) will allow you to instantiate your own Engine class, but as Rob says, it's a lot of effort for little gain. I once succeeded in this using Moles, but just having the engine isn't really enough. You will very rapidly find yourself mocking all sorts of other things that Tridion provides for you via the engine, and you'll probably be writing very much more test code than subject code.
Unit testing and mocking are techniques more suited to object oriented programming, where your test subject is a class, and ideally one that has been factored to a suitable scale. With templating, what you actually need to test is a transformation. To do this, the approach is to have known inputs and to make assertions about the outputs. Of course, you want to keep the scope of each test as small and isolated as possible, just as you would with classical unit testing.
For testing templates, this means creating test components, and some scaffolding templating to allow you to isolate your test cases. For example, you might have a page template that emits nothing but a single component presentation. A web testing framework like Selenium will allow you to make assertions against the outputs. It's not unit testing, but it is automated (or automatable).
If you are interested in testing template building blocks, you might wish to look at the T-Cubed framework, which allows you to control what is in the package before the TBB is executed, and make assertions about what is in the package afterwards.
In the last couple of years, it has become very clear that the future of templating is in the (MVC) web applications themselves rather than on the Content Manager. One of the drivers for this shift of architectures is the difficulty of automated testing using the old approach. With the templating in the application, standard testing techniques can be used, and you'll never need to consider mocking the engine or the package.