EventLogger for MVC application
Again enums should not have any prefix. Drop all those Enum_! You may like to take a look to .NET Naming Guidelines.

Inside the class UserEventLog you do not need to repeat Log prefix for its properties. For example just Message is enough. Think about a Window object: did you ever see properties named WindowTitle, WindowSize, WindowCanMaximize and so on?

Validate values, I might assign null to LogMessage (or an invalid enum for EventType) and it will go straight to the DB engine (which might reject it or not).

Do not hide resolved services in a property like UnitOfWork and UserEventLogService. If you use those objects more than once in the same call then it's a performance hit you do not want to pay (because it has to be resolved for each call and it might event be a new object, it depends on how it's configured in your DI framework). Resolve them once in ctor or better accept them as parameters. 

In addition of a single method Log() with all those parameters you may want to introduce few extension methods (or overloads):

public static async Task LogUserWarning(this EventLogger logger,
                                        DateTimeOffset eventTriggeredOn,
                                        string eventName,
                                        string message)
{
    // ...
}


Think twice before using default values for parameters. If you own this code and the calling code then it's not an issue (probably) but if your code is released as a library, to be used by someone else, then you're introducing a strong contract (simply changing default value will not update callers unless they're recompiled, not to mention that they have to check if new values are what they expect). For a real-world example of this issue you may read Adding option parameter to a library in c# without creating a breaking change
.

Using String.Empty instead of null for a string entry in a DB may be a waste but it depends on DB engine you're using (for example compare SQL Server and Oracle).

I see no reason for EventLogger to do not be sealed.

Do not use System.Web.HttpContext.Current directly. Accessing a static property makes impossible to test your code in unit testing outside an HTTP request. The same is true for GetLocalIPAddress(). If really you can't avoid it then move it to a derived class, at least you can test all the underlying logic in isolation. Better would be to introduce a service to retrieve those information:

interface IHttpRequestInspector
{
    string GetIpAddress();
    string GetAuthenticatedUserName();
}


Now you can create a default implementation using the code you already have but you can also have a MockedHttpRequestInspector class which can be used in unit testing:

sealed class MockedHttpRequestInspector : IHttpRequestInspector
{
    public MockedHttpRequestInspector(string ipAddress, authenticatedUserName)
    {
        _ipAddress = ipAddres;
        _authenticatedUserName = authenticatedUserName;
    }

    public string GetIpAddress() =&gt; _ipAddress;
    public string GetAuthenticatedUserName() =&gt; _authenticatedUserName;

    private readonly string _ipAddress;
    private readonly string _authenticatedUserName;
}


Some properties you declared in UserEventLog are not used in code you show (for example UserEventLog.User). Drop them?