When you work with multiple contexts you have two options:
Treat each context like they were separate applications. Imagine your user is an external resource that you get from a web service. You won't be able to add a foreign key to that. What you would do in this is either add only the userId in your tables and when you need the user details call the external service to get them or have a local light copy of the user in the Bookings context that you would update every now and then from the Users context. This approach is good when you work with a large system and you want to isolate the parts (read about DDD and bounded contexts)
Apart from your 2 contexts, create a third context with the whole model (users, bookings, etc). You will use the complete context to create the migrations and maintain the DB structure, but in the application you will use the smaller contexts. This is a very simple solution. It's easy to maintain the migrations with a single context and it still allows you to isolate the DB operation in smaller contexts that don't have access to unrelated entities.