TheCrimsonHorror

So sometimes we have a WordPress User that doesn't want to share Login Credentials over email because of possible Security issues with emailing passwords. 

One of the easiest ways around this request is just to Inject a new Admin User, Do what you need to do, then delete it. 

INSERT INTO `user_db`.`wp_users` (`ID`, `user_login`, `user_pass`, `user_nicename`, `user_email`, `user_url`, `user_registered`, `user_activation_key`, `user_status`, `display_name`) VALUES ('1337', 'techsupport', MD5('password'), 'Technical Support', 'tech@thecrimsonhorror.com', '', '0000-00-00 00:00:00', '', '0', 'Tech Support');
INSERT INTO `user_db`.`wp_usermeta` (`umeta_id`, `user_id`, `meta_key`, `meta_value`) VALUES (NULL, '1337', 'wp_capabilities', 'a:1:{s:13:"administrator";s:1:"1";}'), (NULL, '1337', 'wp_user_level', '10');

The obvious changes to this would be depending on the specifics of the Database at hand.  After the INSERT INTO you would modify the user_db to be the actual Database name 
The next parts are the wp_users and wp_usermeta These would only change if the customer has modified their Database Prefix (If this is the case, then the wp_capabilities and wp_user_level would also have the wp_ replaced with the Database Prefix)  Modify the Username/Password and email address as needed and just run as an SQL Statement in phpMyAdmin. 

After you're done doing the testing, you want to clean up your User so it's not another entry point for hackers

Of course, the same things for this, change the Database name and Table Prefix to match the database you're working with, and all will be good. 
The UserID set to 1337 is an easy way to ensure that there are no conflicts, it's very unlikely that a user would have that many WP users.