Here is a quite typical situation for a big C/C++ project - some source or header files are generated during the build. I'd rather call them "derived sources". Here are their common attributes:
- used in build and code model
- not supposed to be modified by a human
- produced by a tool been applied to a meta source
Some known examples:
- yacc: .y -> .c
- idl: .idl -> .h
- Tuxedo .mif -> some .c and/or .h
- simple cp: .c -> .c

What kind of support I'd like to see:
1) When user attempts to modify the meta-source he/she is warned and discouraged from doing that (better if the files are detected in an automated way)
2) There is an easy way to navigate from derived source to the parent meta-source, and from a declaration/definition to corresponding structure in meta-source
3) An easy way (like F9) to rebuild a derived source from a meta-source
4) See meta-sources somewhere in the project structure

Some details on difference between Managed and Unmanaged projects in this regard.

Managed:
-------
I assume the fair assumption would be that user adds both meta-sources and derived sources to the project explicitly and very likely specifies the tool to build one from another. So mots of the task is trivial in that case.

Unmanaged:
----------
In unmanaged project usually derived sources are getting added to the project automatically, but not the meta-sources. So there should be some intelligence in Code Model and/or interceptor to identify such derived sources. The tool and meta-source could be detected automatically by interceptor (difficult way), or identified by user either proactively or reactively at IDE request on the attempt to modify a derived source.