The main reason for a primary key is that it defines a unique identifier for a particular record. If you were to be able to make your primary key nullable, then NHibernate would not be able to tell the difference between a newly created record with an empty GUID and a already existing record in your database with an empty or nullable GUID.
So yes, you do not see any examples of this because it would be a very bad practice.
In regards to your example of binding POCO's to a combo box, this is also a bad practice. Following the separation of concerns principle, you would not want to mix your UI logic with domain-specific logic such as the POCOs/entities that you are using with NHibernate to persist to the database. Typically, you would create a ViewModel class that would store whatever data is needed for the UI. You would then have a Service / Business layer which would store the business logic and handle converting/mapping your ViewModel classes to POCOs/entities/DTOs.
So in your example, if the application was following the separation of concerns principle, you would not even run into the issue you are facing because you would not be exposing the objects you wish to create/save/update using NHibernate. Separating your application in this way provides many other benefits such as not directly tying your database architecture to your UI, allowing you to easily modify the UI, Service Layer, or database without dramatically impacting any other layer, etc.