SMO : The login already has an account under a different user name, when calling TransferData()
First, if you do both:
GRANT VIEW ANY DATABASE TO [username];

and
DENY VIEW ANY DATABASE TO [username];

the DENY still wins, so there was no sense to grant it, this is also the default permission that every new login has so there was no need to grant it again.
Second, you don't see the difference between database principal dbo and any member of the fixed database role db_owner. When you make some user a member of db_owner this user has all possible permissions in this database. But this has nothing to do with the fact &quot;to see some database in Object Explorer&quot;.
To &quot;see&quot; any database in OE, login should have view any database permission.
Login and not user. So your login can has no view any database permission but still be a member of db_owner role, in this case user has all the permissions in that database but it cannot &quot;see&quot; any database in OE.
Dbo database principal is a special principal where any sysadmin (i.e. a member of sysadmin server role) is mapped, and the OWNER of database is also mapped to dbo.
The owner of database is one and only one login that created this database or was assigned to be database's owner by executing alter authorization statement:
ALTER AUTHORIZATION ON DATABASE::Dinesh TO [username]

This way you assigned the LOGIN username to be the owner of this database. The owner of database is of course a member of db_owner role but not vice versa. DBO will always &quot;see&quot; the database it owns in OE as any sysadmin will.
To your question:
the error you receive tells you that you cannot execute
CREATE USER [username] FOR LOGIN [username]

Because the LOGIN username is already mapped to this database, as dbo.
So you cannot re-map it to another username.
If you want your script to run without errors change the database owner to any other login, for example to sa login, this way the login username can be created in this database.
Then if you want your username to be database owner just drop your user username from this database and alter authorization to username, this way it will be mapped to dbo.
Alternatively, if you already know that you want this user to be database owner, drop the user username from your database prior to transfer and it still be there in the database as it is mapped to dbo.

So if then I create another login and I execute:
USE master; GO ALTER AUTHORIZATION ON DATABASE::dbName TO
[anotherUser]; GO Now username can not access the database.

This is because as I explained above, database OWNER can be only one login at a time. If you want your ex-owner to access this database you should map it:
USE dbName; 
CREATE USER [username] FOR LOGIN [username] ;
GO

You don't need to map a login to database only if it is sysadmin or database owner (which, I repeat it, can be only one). Any other login should be mapped to database (create user for login) in order to access it.