There are several changes I would propose here. I will try and tackle them one an a time. I will include some snippets as we go along but the end will contain the whole code.

Redundant call to Get-ADDomain

It looks like you only have the one domain. Get-ADUser will automatically call the domain your are attached to. You don't need this unless you have multiple domains.

Calling Get-ADuser twice

You call Get-Aduser to get all users. Then you cycle each one and call Get-Aduser again! No need for this. Lets just do it once and use the pipeline to process. I would like to point out that Select * that you use is not required, in this case, and can be harmful as it can changes the membertypes of object properties. I will come back to this later.

Instead lets do want you intended. Grab all enabled users in one line. Keep reading to see what -Properties $properties is all about.

$allEnabledUsers = Get-ADUser -filter {Enabled -eq $true} -Properties $properties

Also you would never get duplicate users. -Unique would not serve a purpose. They could have the same displayname, surname and firstname (as well as others) but the user would need to be unique in several other aspects.

Performance issue querying AD

You are using -Properties *. This will pull all properties of the filtered objects. You however are ignoring most of these in favour of about a dozen. Instead we should get the properties we are going to use. Also need to keep in my that by default some of these are already returned by default.

$properties = "EmailAddress", "GivenName", "Department", "DisplayName", "Company"
Get-ADUser -filter {Enabled -eq $true} -Properties $properties 

Unnecessary object creation

Get-AdUser is already outputting objects no need to recreate new ones when we have almost the ones you want. Also, depending on how many users you have, the $UserArray += $UserData code can be costly from a performance perspective since the array is destroyed and recreated with the extra user appended. With 1000's of users this can add up. We can use the pipeline to mitigate this as well. You are just using different names for the properties so lets use calculated properties to do just that. Depending on how you like the readability of this you can easily make a function to do this but this does make sense so it is a personal choice if you choose to make that function.

This part of what I do could be biased and other might be fine with object creation. If you still op to do this I would at least use the type case [pscustom] on a hashtable. Simple example of this can be found on this blog which show some different approaches to object creation.

Multiple consecutive calls to write-host

I would love to introduce you to splatting. It is useful when you are calling cmdlets and using the same or similar parameters sets. Basically feed a hashtable of arguments to the cmdlet. Also write-host does take pipeline input so lets send the properties, set for Red, as an array. It keeps the code to as minimum as it gets.

I will show this but I caution that this a lot of information you are putting on the screen. You are already outputing it properly so I don't see the need for the wall of colour you would be creating.

Wrap it up

At the end you sort the object and output to CSV. Everything done up to this point allows us to use the pipeline so we do not need separate statements for this functions. We can still put them on separate lines for readability.

# Output parameters
$consoleOutputParameters = @{
    foregroundcolor = "green" 
    backgroundcolor = "black"
}
# Set output file path
$userCSV = "C:\temp\users.csv"
# Non standard properties to query
$properties = "EmailAddress", "GivenName", "Department", "DisplayName", "Company"
 # Grab a load of user object information from AD 
$allEnabledUsers = Get-ADUser -filter {Enabled -eq $true} -Properties $properties

# Build the calculated properties list for custom header output
$outputProperySet = "Name",
        @{Name="E-Mail Address";Expression={$_.EmailAddress}},
        @{Name="First Name";Expression={$_.GivenName}},
        @{Name="Last Name";Expression={$_.Surname}},
        "Department",
        @{Name="Display Name";Expression={$_.DisplayName}},
        "Office",
        @{Name="Phonetic Company Name";Expression={$_.Company}},
        @{Name="Phonetic Display Name";Expression={$_.DisplayName}},
        @{Name="Phonetic First Name";Expression={$_.GivenName}},
        @{Name="Phonetic Last Name";Expression={$_.Surname}},
        @{Name="Phonetic Department";Expression={$_.Department}}

#Loop through each name in the generated list
$allEnabledUsers | Select-Object $outputProperySet | ForEach-Object{
    # If you choose not to use any console output this whole ForEach-Object can be removed. 
    # Output process on screen. Set the Name to green
    $consoleOutputParameters.foregroundcolor = "Green"
    Write-Host $_.Name @consoleOutputParameters
    # The rest of the properties are Red
    $consoleOutputParameters.foregroundcolor = "Red"
    $_."E-Mail Address",$_."First Name",$_."Last Name",$_.Department,$_.Office,
            $_."Phonetic Company Name",$_."Phonetic Display Name",$_."Phonetic First Name",
            $_."Phonetic Last Name",$_."Phonetic Department" | Write-Host @consoleOutputParameters
    # Throw a blank line to split the content
    Write-Host ""
} | Sort-Object Name | Export-Csv -Encoding UTF8 -LiteralPath $userCSV -NoTypeInformation

# Display a summary on screen. 
Write-Host ("Total Number of Unique Users found: {0}" -f $allEnabledUsers.Length)

I want to call attention to something I wrote above just one more time. If you choose not to use any console output the ForEach-Object could be removed. If you have a requirement to show that on the screen then leave it.

There are some more property loops you could use. For example the one you see for write host. However readability starts to be affected so I think what I have shown above is a good compromise.

Note I have put the code comments above the lines they describe that is both a personal preference and something that makes code easier to read on Stack Exchange. I see no reason outside those two points to change how you have your comments.