Yes, mock objects would help. Essentially, you create a fake Mapinfo object by mocking the Mapinfo interface (you should rename that IMapInfo, btw).
You then instruct that mock what calls to expect, and what results to return (if appropriate). You can also create tests where the mock throws exceptions or does other things that are hard to invoke using the real object.
The two big (and free) .NET mocking frameworks are MoQ and Rhino Mocks. Rhino is more mature and has more ways of configuring mocks. MoQ is the newcomer and has a smaller featureset and less ways of setting expectations than Rhino.
Personally, I think MoQ is better for the newcomer to mocking. Its relatively easy to understand, all the documentation out there is relevant to the current release (search for Rhino tutorials and you get junk from years ago that doesn't apply anymore), and it performs well.
I'm answering my own question here, after talking to Matlab tech support: There is no equivalent of Nothing, and Matlab does not support this.
In detail: Matlab does support optional arguments, but does not support passing in variant NULL pointers (actually, to follow exactly how VB's Nothing works, a VT_EMPTY variant, I think) whether as an optional argument or not. There is documentation about some null / pointerish types, a lot of which is mentioned in my question or in various answers, but these don't seem to be useable with their COM support.
I was given a workaround by Matlab support using a COM DLL they created and Excel to create a dummy nothing object that could be passed around in scripts. I haven't managed to get this workaround / hack working, and even if I had unfortunately I probably could not redistribute it. However, if you encounter the same problem this description might give you a starting point at least!
Edit
It is possible this Old New Thing blog post may be related. (I no longer work with access to the problematic source code, or access to Matlab, to refresh my memory or to test.)
Briefly, for IUnknown (or derived) parameters, you need a [unique] attribute for them to legally be NULL. The above declaration required Matlab create or pass in a VT_EMPTY variant, which it couldn't do. Perhaps adding [unique] may have prompted the Matlab engine to pass in a NULL pointer (or variant containing a NULL pointer), instead - assuming it was able to do that, which is guesswork.
This is all speculation since this code and the intricacies of it are several years behind me at this point. However, I hope it helps any future reader.
Best Answer
If you're asking the more general question about how COM events work (from any client, not just IE which has some specific requirements around security, etc.) and how to expose your objects' events, then there's a good CodeProject article, Understanding COM Event Handling, which has lots of details about how COM event handling works. Plus a C++ sample (which doesn't depend on ATL or MFC) to illustrate how to host events. Warning: this is a pretty complicated article, but if you can get through it and understand it, you'll have a good background on how COM events work.
If you're specfically asking how to expose your COM objects into javascript so they can be called from Internet Explorer, then how to create an activex control that fires events to javascript (without using ATL) is a good blog post that discusses exactly what you need to (as the title suggests) expose your COM objects to javascript, including all the IE-specific goo.
BTW, unless you have a good reason not to, I'd suggest using ATL to handle your COM support, exposing your events, etc. You can do it in plain, no-dependency C++ (as the article above does) but ATL makes things easier. A reasonable starting point is MSDN's ATL Events section, but I'd definitely read the CodeProject article first for some general background info before diving into the MSDN stuff.
Answering your specific question about IDispatch and events: events don't have to use IDispatch, and clients can talk directly to your C++ event-handler implementation. But most if you want your events to be handled by IE, by javascript, by VB6, and other automation-only apps ("automation" is the COM term for clients using only IDispatch to call properties, methods, and events on COM objects). Most event-sending apps, for this reason, use what are called "dual interfaces" which (in their C++ implementation) inherit from both IDispatch and your custom events interface, and end up calling the same code under the covers. ATL makes it really easy to build such a dual-interface COM component.