Is there any point in specifying a Guid when using ComVisible(false)?

Having [assembly: ComVisible(false)] and [assembly: Guid("...")] at the same time makes perfect sense in certain cases. You start with an empty assembly and will perhaps want to expose something from it to COM. So you mark the assembly as not ComVisible and later mark the entities to expose as ComVisible. That is why the GUID exists by default.

Regardless, if you really don't want to expose anything from your assembly to COM leave the "Register for COM interop" option unchecked in the project settings.

Consistent GUIDs are absolutely essential in COM. The [assembly:Guid] attribute generates the type library LIBID. Surely the project template auto-generates one to make sure that the programmer doesn't forget to provide one when s/he flips ComVisible to true.

If an assembly [Guid] isn't provided then Tlbexp.exe synthesizes one from the assembly name, version and public key. That's not really good enough, type libraries already have a version. Changing [AssemblyVersion] would generate a different LIBID. Especially bad when you use the auto-increment option for the version (like 1.0.*), you could quickly fill the registry with a mountain of dead TypeLib registry keys.

Long story short, it avoids a lot of nasty mishaps.

Nope, no real reason to include it. It's really pretty unnecessary except in very specific COM interop scenarios. Though I suppose there could be something useful about having a GUID that you can access with reflection. But since it's not guaranteed to be there, its not like you could rely on it.