Hi Brian,
I've only ever used OpenXML once and it has been a while, so take that with a grain of salt, but:
I think a direct cast is not possible.
And more importantly, I think it most likely wouldn't make sense to do that, either.
It's best to use the usual COM methods, and not OpenXML, to add CustomXMLParts to an open workbook.
In not-so-short:
The COM model (= essentially what ExcelDnaUtil.Application returns, and everything in the Excel.-namespace) has a fairly different purpose to what OpenXML does.
The COM model lets you interact with a running instance of the Excel application itself. I.e. the user must have Excel open and running, and then you can modify stuff in it. It's basically just a way of communicating with Excel and telling it what to do (e.g. "set cell value to ABCDEF - Excel will do it for you, the user will then see it right on screen etc.).
OpenXML intends to let you work with the Office file (!) format.
It doesn't let you interact with a running session of Excel; in fact, it doesn't even require the user of your software to have it installed on their machine at all.
So its main purpose is reading and writing Office files, without needing to fire up the actual Excel application for it. Think of webservers reading/writing reports, anti virus scanners scanning worksheets for malware etc.
Trying to interact with stuff (workbooks etc.) that are currently open and being worked on in Excel using OpenXML is usually a bad idea.
Reading a file that is already open in Excel will work to some extent, but they won't be synchronized to the open workbook (e.g. if the user makes any changes in Excel and doesn't save the file, you'll never know).
Modifying an open file will pretty much never work, because A) the changes wouldn't feed through to open Excel instance, and B) the workbook file - if there even is one - will most likely be locked by Excel anyway (unless its opened in non-exlusive file mode, but that raises even more problems).