You've got it right, and this is what DDD invariants are all about. By making entities enforce their own integrity (or an Aggregate root enforce invariants for its aggregate), you ensure that your domain objects are always valid.
The argument of "loading data into the model" is a strange one since there's little value IMO in loading an invalid entity - a "cyclops with 2 eyes" or a Thing
with null Properties
in your example.
Sure, if your properties are readonly, you won't have access to an inline object initializer but there are other convenient ways of instantiating an entity (that is, a valid one) in one go : constructors, Factories, custom Builder pattern, etc. Besides, if you're talking about rehydrating domain objects from a persistent data store, most ORM's have the ability to manipulate private or protected fields so there's nothing to worry about.
Also note that functional programming techniques might make this easier to implement : immutability by default, non-nullable types...