Microsoft LAPS, https://support.microsoft.com/en-us/kb/3062591, doesn't handle user creation that well, and GPP is deprecated since ms14-025. Might get solved with startupscript (tested on win10)

Manage-LocalAdmin.ps1

#Microsoft LAPS, https://support.microsoft.com/en-us/kb/3062591, doesn't handle user creation that well, and GPP is deprecated since ms14-025
#might get solved with startupscript (tested on win10)

#get users in local administrator
$obj_group = [ADSI]"WinNT://$($env:COMPUTERNAME)/Administrators,group"
$Administrators = @($obj_group.psbase.Invoke("Members")) | foreach{([ADSI]$_).InvokeGet("Name")}

#get local users
$adsi = [ADSI]"WinNT://$($env:COMPUTERNAME)"
$Users = $adsi.psbase.children | where {$_.psbase.schemaClassName -match "user"} | select @{n="Name";e={$_.name}}

#if user customadmin does not exist, create one
If(!($Users.Name.Contains("customadmin"))){
                $cn = [ADSI]"WinNT://$($env:COMPUTERNAME)"
                $user = $cn.Create("User","customadmin")
                $user.SetPassword($(([char[]](50..150) + 0..9 | sort {get-random})[0..18] -join ''))
                $user.setinfo()
                $user.description = "Local Admin User"
                $user.SetInfo()
                Write-Output "User customadmin was created."
}Else{
                Write-Output "User customadmin already exists."
}

#Add to Administrators group
If(!($Administrators.Contains("customadmin"))){
                $OBjOU = [ADSI]"WinNT://$($env:COMPUTERNAME)/Administrators,group"
                $objOU.add("WinNT://$($env:COMPUTERNAME)/customadmin")
                Write-Output "customadmin was added to Administrators."
}Else{
                Write-Output "customadmin is already member of Administrators."
}

This way of creating users has the same security issue as GPP had, being the password in semi-cleartext in the script.
The idea is to just create a user, and let LAPS handle the password afterwards, so the "customadin" has the password specified in the script only for a limited time.

LAPS can also handle the built-in local administrator (rid-500) acount.
Microsoft has multiple points of view about handling the local administrator, some say disable it, some say to use it. In my humble opinion, I would disable it...
But then you need another account to manage, and there is currently no way of creating one using Group Policy...