Is there a way to do this 100% reliably? I don't think so. The only way I've ever been able to tell if a file is autogenerated or not is by its content or by its filename.
Often, generated code files in newer versions of (what I know) C# have a ".g." within their names. This is not written in stone or guaranteed (I think windows forms and other older generators use ".Designer."), but it can be used as an indication.
If you look through different autogenerated code, you'll see there are a number of different ways it can be marked. There is no specific way that is universal. For example, autogenerated wire-up code in WPF codebehind files (the hidden InitializeComponent() method resides there) contains a partial class definition marked with the System.CodeDom.Compiler.GeneratedCodeAttribute and the methods are all marked with the System.Diagnostics.DebuggerNonUserCodeAttribute.
The first attribute resides on the class, so it may show up when inspecting the code via EnvDTE methods. You might have to resort to reading the file in raw and looking for that attribute.
Even this isn't enough information, as different code generators mark their code differently. Type safe DataSets and EF generated code mark their generated code with a comment at the top of the file
//------------------------------------------------------------------------------
// <auto-generated>
// This code was generated by a tool.
// Runtime Version:4.0.30319.551
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------
What now?
Unless you explore all the different ways autogenerated code is marked, and handle them all, there isn't any way (unless I'm missing something!) you can guarantee skipping these files. You have to ask yourself if it is worth the effort.