I recently picked up a book on ATL and started learning about the basics of COM development.
Put the book down, and back away slowly.....
Considering that you would have a well-known engine interface between the engine and the game, and that as the engine matures and adds features, the interface can be easily improved and used, I think it's quite possibly a working solution.
Not with COM you can't. With COM you stick to a pre-defined rigid interface. As you add features to your engine, your support burden increases as you support this iteration, and all previously published interfaces. If you screw up one of your earliest interfaces, you'll be fighting that design decision for some time to come (and you'll have methods suffixed with '2', or 'Ex' in the case of the WIndows32 API).
You could then basically just distribute the DLL and the interface and new games could take advantage of the features by retrieving a newer interface from the DLL.
You could, but they you'd have to start adding a tonne of versioning and DLL validation checks to your code. You'd also have to validate that each of your DLL builds in binary and backwards compatible with the previous versions. It would be far too easy for this to go wrong in practice. This approach *might* make sense if you're in the business of writing operating systems (or middleware at an extreme push), but it's not going to be that useful for a single game release. Just ship your game binaries in a single installer, rather than having an 'Engine V1' + 'MyGame' installers.