Добавив в таблицу User поле FavoriteTeamId и сделав его nullable.

fkthatВариант с промежуточной таблицей тоже вполне жизнеспособен.
Жизнеспособен. Но, с одной стороны, предпочтителен весьма редко и в ситуациях, когда таких вопросов обычно уже не задают. С другой стороны, если такая необходимость когда-нибудь нарисуется - материализуется из первого варианта буквально одним движением (скажем, в Oracle - достаточно просто создать индекс по этому полю, он по сути и будет такой "промежуточной таблицей"). С третьей - перейти в направлении от второго варианта к первому может быть достаточно сложно (добавление поля в гигантскую таблицу - то ещё удовольствие). Поэтому по умолчанию и в соответствии с уровнем вопроса я однозначно рекомендую первый вариант.

fkthat,

паспортные данные, как правило, стоит вынести в отдельную таблицу не потому, что они "одновременно null", а потому, что документ - это совершенно отдельная от человека сущность со своим жизненным циклом, и бизнес-логика наверняка потребует таких кейсов как "Иванова вышла замуж" или "Петрову неправильно вбили номер паспорта". Чем больше бизнес-логики ляжет на "любимую команду" - тем больше причин вынести её в отдельную сущность, но здесь уже прогноз не так однозначен, как с документами.

Что же до самой по себе группы полей, то для реализации такого требования достаточно очевидного check constraint-а, применять что-либо более масштабное, имхо, не требуется.