In Entity Framework and the repository pattern, where should DB exceptions be handled?

How would you implement the repository pattern, Entity Framework 4.1, and Code First in this scenario: The projects listed below are included in the Visual Studio solution.

Solution
|-Web Application Project
|-DAL Project
|-Model Project

There are thus many courses in the Model Project. Let's say there is a class named User with the (simplified) definition as follows:

public class User{

    [Key]
    public int UserId { get; set; }

    ....

    //this property has a unique constraint created in a custom DB Initializer class
    public string email { get; set; }

    ....
}

The repository methods (Insert, Update, etc.) and the Initializer class are located in the DAL project:

public class MyDatabaseInitializer : IDatabaseInitializer<MyDatabase>
{
    public void InitializeDatabase(MyDatabase context)
    {
        try
        {
            if (!context.Database.Exists())
            {
                context.Database.Create();
                context.Database.ExecuteSqlCommand(
                    "ALTER TABLE Users ADD CONSTRAINT uc_Email UNIQUE(Email)");
            }
        }
        catch (Exception ex)
        {
            throw ex.InnerException;
        }
    }
}

My Unit of Work class's Commit function looks like this:

public string Commit()
{
    string errorMessage = string.Empty;

    try
    {
        Database.Commit();
    }
    catch (DbUpdateException updExc)
    {                                 
        errorMessage = updExc.InnerException.Message;            
    }                       

    return errorMessage;
}

As you can see, I manageDbUpdateException in theCommit() This indicates that any class that may result in an update error would be handled in this function of the Unit of Work class.

Let's say the following information is inserted into the User records:

(UserId,....,Email,...)
1, ... , person1@mail.com , ...
2, ... , person1@mail.com , ...

It is evident that a DbUpdateException would result from this. Of course, this is contagious and spreadable to the location where it ought to manifest. This design, in my opinion, is wholly flawed:

1. Each property should be validated independently; shouldn't the same be true for a field's unique value? Do I have to combine DAL and MODEL into a single project as a result?

2. How would I deal with problems brought on by a breach of the uniqueness for fields A and B in table A and field C in table C? It's not very clear to use error messages like "The value already exists" or "Uniqueness violation"!

3. Should I add a new project with a business layer that handles this kind of error handling?

4. Should I handle the updates' Action/Controller (ASP.NET MVC) error handling?

5. How should an application that supports many languages handle an error message?