User assignment to various roles of changing events
First, I would expect there to be a team table:

 TeamId | TeamName
--------+----------
    1   |  Team A
    2   |  Team B


and a separate user table, that identifies the team each user is in:

 UserId |   UserName   | TeamId
--------+--------------+--------
  1001  |   JaneSmith  |   1
  1002  |   JohnJones  |   1
  1003  |   KatieGrin  |   1
  1004  |  AbeSimpson  |   2
  1005  |  BenFranklin |   2
  1006  |  BarbaraEden |   2


Then, assignment would have UserId as a foreign key referencing the user table, just like TeamId in user is a foreign key referencing team.

I would not see value in having separate tables for each team. That would actually make things harder, rather than easier. The assignment table would either need one extra column, to indicate which table the assigned user came from (complicating queries, and preventing most common means to enforce referential integrity), or it will need a unique column to tie back to each distinct team table, in which case each foreign key column would need to allow for NULLs, which can hurt your referential integrity again.

Usually, the main benefit of using an actual value instead of NULL is to avoid the need for functions in your query to adjust the NULL value to as appropriate value. However, using 999 would probably still require some sort of computation, to adjust it to the actual DayEnd.

I do wonder if you wouldn't be better off using the actual DayEnd. I assume you're doing this to avoid having to recalculate the DayEnd values for an event that's duration changes; however, consider carefully if that's really the way you want to go. With NULL (or 999) as your DayEnd, you assume the users can safely be assigned to additional days. I don't know your business rules, but it seems entirely possible that someone may be unable to cover the additional days added to the event; assuming they can cover the additional days simply doesn't seem particularly safe.

Full details on implementation would, of course, depend on your DBMS, and your full business rules.