a) A domain entity may occasionally create or delete other entities. However, it will typically do so by adding to or removing from one of its internal collections if the entity to add/remove is one of its child entities from the same aggregate (in which case your ORM will most likely be able to track changes to the collection and persist them automatically), or by calling a Repository if the entity to create/delete is an Aggregate root. It hardly seems appropriate for a domain object to know about the unit of work and the current state of objects in the user transaction - this is a job for the Application layer.
You should also be careful not to place too complex object creation logic in an entity - assembling complex objects from various parts rather belongs to a Factory.
b) There's elegance indeed in code that mirrors how real-world concepts play out - it's smooth, very readable and easily understandable. Besides, it's true that DDD encourages us to name our code constructs after real world concepts of the domain.
However, it also tells us that the model and ubiquitous language should be the result of a domain expert/developer collaboration. It's not like you could just pour the domain on a keyboard and watch your domain objects write themselves magically. Abstraction is not just translation from real to code with nouns becoming classes and verbs becoming methods, it's more than that. Some kind of transformation process is needed where the business needs and technical needs meet. During that process, some objects or relationships between objects that existed in the real world will be preserved, others won't - because they are not conveniently representable in code, or because they defeat good software practices such as separation of concerns, cohesion, low coupling, etc. New domain objects will also appear, maybe ones that don't have a materialization in the real world domain.
So the computerized version of a real-world domain problem or activity is a different animal, there's no rule allowing you to tell in advance if there's going to be a class for this business actor or a method for that business concept. All you can be sure about is that their names will probably be found somewhere in the code.