Guid of created aggregate root in CQRS

Looking at this code from here:

[Serializable]
public class CreateClientCommand : Command
{
    public string ClientName { get; private set; }
    public string Street { get; private set; }
    public string StreetNumber { get; private set; }
    public string PostalCode { get; private set; }
    public string City { get; private set; }
    public string PhoneNumber { get; private set; }

    public CreateClientCommand(Guid id, string clientName, string street, string streetNumber, string postalCode, string city, string phoneNumber) : base(id)
    {
        ClientName = clientName;
        Street = street;
        StreetNumber = streetNumber;
        PostalCode = postalCode;
        City = city;
        PhoneNumber = phoneNumber;
    }
}

The Guid here is just relevant for the command. It is not the Guid of the (potentially) created aggregate root. What is the best practice to obtain this Guid and how are any potential validation errors communicated back to the the code that puts a command on the bus? For example like this:

_bus.Publish(new CreateClientCommand(
     Guid.NewGuid(),
     _clientDetailsReport.ClientName,
     _clientDetailsReport.Street,
     _clientDetailsReport.StreetNumber,
     _clientDetailsReport.PostalCode,
     _clientDetailsReport.City,
     _clientDetailsView.PhoneNumber));

_bus.Commit();   

I understand that CQRS usually implements eventual consistency. This means that it might take a while before the client is actually created. Some MVC/CQRS code uses this approach:

[HttpPost]
public ActionResult Add(DiaryItemDto item)
{
    ServiceLocator.CommandBus.Send(new CreateItemCommand(Guid.NewGuid(),item.Title,item.Description,-1,item.From,item.To));

    return RedirectToAction("Index");
}

Obviously, the index page might show some grid containing the DiaryItems and the user might be able to see the latest created DiaryItem (potentiality after a while). Any feedback would be very much appreciated. Thanks.

Are you asking about the distinction between an ID for the command itself, versus the ID of the entity it might create? The former would typically be an infrastructure concern, found on something like a message envelope, buried in a RPC protocol, or the like. The latter would be part of your domain. (Though in many cases, it's nice to treat the ID of an entity as an infrastructure concern as well, since you might choose it for convenience in your persistence model.)