I know I can read the CLSID from a COM class object in the registry from Classes\<CLASSNAME>\CLSID\@.
I suspect on a registered COM interface I can read up the IID from Classes\<CLASSNAME>\IID\@ or Classes\CLSID\<CLSID>\IID.
I've read the article COM IDs & Registry keys in a nutshell and this question is still open to me. Unfortunately, I have no test case right now.
The registry was not meant to be a programming resource, registry entries are only there when the COM infrastructure needs them. The CLSID key for example is necessary to help COM find the executable file that implements a server, the programmer has to supply the CLSID guid.
He needs to know the IID as well, passes it to QueryInterface() to obtain the interface pointer. There might be an entry in HKLM\Software\Classes\Interface but it isn't terribly common. The COM infrastructure needs it when an interface needs to be marshaled from one apartment to another, the registry key contains the CLSID of the proxy that helps to get that job done. A quick look with Regedit.exe in that key ought to convince you that it isn't likely to be helpful at all, there is no connection whatsoever with the server itself. Only if you are very lucky might you find a Type library LIBID there.
There are two basic ways that the COM programmer supplies you with CLSID and IID values. The unfriendly way is an .idl or .h file, several Windows components (DirectX, Media Foundation, WASAPI, etc) are like that. Good enough to see the IIDs back.
The friendly way is a type library, a language-independent description of the implemented coclasses and interfaces that just about any compiler knows how to read. Sometimes supplied as separate .tlb or .olb file but usually embedded as a resource in the executable file. Best way to have a look at it is with the Oleview.exe SDK utility. Use File > View Typelib and select the .tlb or .dll file. It decompiles the type library back into IDL, the language that a COM author uses to describe his component. You'll have no trouble finding the IIDs back. Only thing you have to know is the name of the executable file.
Be sure to take advantage of the type library in your compiler, assuming you found one. You can now use friendly names instead of raw GUIDs, get syntax checking on your code and rarely have to do anything dramatic when the version changes and the author properly used new IIDs. Be sure to talk to the author if you can't find one, a small hint can save you an enormous amount of trouble.