So with regular COM AddIns in Outlook, to expose your COM Add-In to external applications involved setting the Application.ComAddins.Item("ProgID").Object property equal to an instance of the object. Typically, in your OnConnection event handler, you'd do something like this:
Application.ComAddins.Item("PROGID").Object = Me
That allowed external code to get a reference to your COM addin class through its Object property and call public functions on your addin. With VSTO 2005 SE with Outlook 2007, we have a new (better) way of handling this scenario.
There is a new virtual method which you can override and specify ANY object to be set in that value when the add-in is created.
You do this by overriding the RequestComAddinAutomationService method in your VSTO add in. See the following MSDN article: http://msdn2.microsoft.com/en-us/library/microsoft.office.tools.addin.requestcomaddinautomationservice(VS.80).aspx
The article on MSDN actually has a good example of what you need to do. Just realize that you do have to include the attributes on your interface class to make them IDispatch and ComVisible.
You're right, the whole thing is working, but only up to the point where I want to query the .Object property from my own C# code - I get back a System.__COMObject which cannot be cast to my interface...
I see you have already posted on Andrew Whitechapel's blog post on the same subject (http://blogs.msdn.com/andreww/archive/2007/01/15/vsto-add-ins-comaddins-and-requestcomaddinautomationservice.aspx). I will defer to him as he is the resident VSTO expert.
I will say that the intended purpose of this method was to expose your VSTO add-in to other Add-ins theoretically running in COM including VBA. That being said, it seems like you should be able to use it in .NET as well. I'll let Andrew Whitechapel answer you though.