И в чем же разница, которая должна быть сразу видна?
Во-первых, ни то ни другое работать не будет, потому как перед тем как раздавать права на использование процедур надо добавить в базу соответствующих пользователей с помощью sp_adduser.
Во-вторых, непонятно что значит [NT юзер] в предложении
> "grant execute on xp_sendmail to [NT юзер]"
на уровне объектов базы разрешения даются пользователям БД а не логинам сервера, так что в качестве [NT юзер] не допускается конструкция [Domain\User], что судя по всему имелось ввиду.
А в третьих, если все сделать нормально, то и разницы никакой не будет...

exec sp_addlogin 'test'
use master
exec sp_grantdbaccess test
grant execute on xp_sendmail to test

exec sp_grantlogin 'domain\test'
use master
exec sp_grantdbaccess 'domain\test', test2
grant execute on xp_sendmail to test2

Вдогонку :
The fact that the names of users and groups may be different from SQL Server 2000 to Windows does not cause any security problems. The permissions set for the user or the group continue to function correctly, as SQL Server relies only on the SIDs internally.
(c)http://www.microsoft.com/sql/techinfo/administration/2000/2000SecurityWP.doc
стр. 36

По некоторым размышлениям и дополнительному изучению мат части надумал вот чего:
Все таки наверное это не баг. Пользователь NT может являться пользователем БД через NT группу. (т.е. для группы сделан вход на SQL Server и соответственно для него сопоставлен пользователь БД). Далее может понадобиться дать какое либо разрешение на объект БД этому пользователю (только ему, а не всей группе), но при этом не давать ему отдельного коннекта к БД, т.е. не сопоставлять отдельного пользователя БД. Тогда пока он (NT юзер какими то окольными путями (через NT группу) может обращаться к БД, у него будет право и на тот объект, который был прописан исключительно для него). Как только он перестанет иметь вход в БД (перестанет быть членом этой NT группы), то соответственно и его индивидуальное разрешение ему ничего не даст. Судя по всему задумка заключается именно в этом. Но кроме того, что доступ к БД можно через выделенного пользователя и через группу, можно еще иметь его и через guest. Именно по этому и получилось для NT пользователя обеспечить права на xp_sendmail. Кстати, в EM можно видеть что при таком добавлении пользователя в столбце DataBase Access для него указывается "Via group membership". На уровне системных таблиц обеспечивается такое членство указанием значения 0 в столбце hasdbaccess таблицы sysusers.
Поскольку SQL юзер не может обратиться к БД через группу, то и входа "Via group membership" для него не предусмотрено. Но что при этом действительно странно - то что MS почему то "забыли" что и SQL юзер может обратиться к БД через guest....

И еще насчет отличий - насчет xstatus.
Выше Glory привел табличку. В ней для всех приведенных пользователей первые два бита одинаковы. По-моему, именно они представляют наибльший интерес, а 2-ой и 3-ий носят скорее информативный характер. Бит hasaccess имеет примерно тот же смысл что и столбец hasdbaccess в sysusers, только на уровне сервера. И что интересно, для NT пользователя он имеет смысл, т.е. сбросив его отменим NT юзеру право на коннект к серверу (если только он не имеет входа через NT группу). Настройки пользователя при этом остаются в силе, т.е. он не удаляется начисто. SQL же юзер к этому биту нечуствителен, т.е. сбросив для него этот бит право на вход унего не отберем. Аналогичная ситуация с первым битом (DenyLogin). Собственно для NT юзера запретить логин можно и штатными средствами. Но вот что мне всегда не нравилось - это то что SQL юзера нельзя временно заблокировать. Т.е. закрыть ему вход, но не удалять насовсем (чтоб через какое то время при необходимости восстановить его не пришлось вновь прописывать все разрешения). Можно было бы надеяться что отца русской демократии спасет этот первый бит, но увы - к нему SQL юзер также нечуствителен...

P.S. 2 TIgr: Ваш пример действительно работает, я его применил для другой БД где не было guest и соответственно вход NT юзера через него не прошел, поэтому скрипт у меня отработал с ошибками в обоих случаях. Кстати, зато на других БД интереснее испытывать, поскольку там можно удалять guest-а в отличии от master и при этом соответственно пропадают права NT юзера на объекты БД, да и скрипт начинает отрабатываться с ошибкой