Telling a client that there is no result via the DTO pattern
I only quickly glanced at your code, so this isn't going to be a thorough review, but I think the basic idea is surprising:

Service never returns null or throws exceptions.

I think this approach is error-prone. When I call a method called GetUserById, for an Id that doesn't exist, I expect either an ArgumentOutOfRangeException (or similar), or a null return value - the last thing I expect is a valid object filled up with default values filling up all members.
As @jlnorsworthy mentioned in his excellent comment, your approach is far from instinctive. Instead of:
var userDto = UserService.GetUserById(1);
if(!userDto.Response.HasValue)
{
      //No result is available
}

I would perfer to have:
var userResult = UserService.GetUserById(1);
if(userResult.Result == null)
{
      //No result is available
}

Also HasValue confusing because it is a well-known member of Nullable&lt;T&gt;, so I'd consider changing EntityId to be Nullable&lt;long&gt; or Nullable&lt;Int64&gt;:
public bool HasValue
{
    get { return EntityId.HasValue; }
}


What is IRepositoryLocator? If it is what I think it is, you should read up on Mark Seeman's blog. Shortly put:

Service Locator is a well-known pattern, and since it was described by Martin Fowler, it must be good, right?
No, it's actually an anti-pattern and should be avoided.


Little nitpick, I wouldn't use ForEach here:
public void AddBusinessWarnings(IEnumerable&lt;BusinessWarning&gt; warnings)
{
    warnings.ToList().ForEach( w =&gt; _businessWarningList.Add(w));
}

It would be much more readable (and less semantically controversial) to write it like this:
public void AddBusinessWarnings(IEnumerable&lt;BusinessWarning&gt; warnings)
{
    _businessWarningList.AddRange(warnings);
}