Generally, databases reflect reality (:-]). There is only 1 "events" entity. There may however be more than 1 "people" entity. But only if one group of people never take part except in one specific way (or almost never and you're willing to live with the exceptions), and only if it really matters.
That being said, given what you've said, I think I'd split Guests, Vendors and Staff into 3 tables. Depending on complexity all 3 may be have access to tables like Notes, Calls, Address, Phones, ie., anything that "any person" would need. Normally I'd have multiple ID fields in these kind of tables, one for each (3 in this case). Alternatively you could have only 1 ID field, with different prefixes on the ID for each type (in each parent table).
The general idea is that each group has its own operations which do not overlap. You never do the same kind of thing with more than one group. And if you do, like a Find on a name, or sending all of them a letter, you handle that within a script.
It also means however that each group would need its own "join" table between its parent table (Guests for example) and Events. Alternatively, you could have 1 join table, and a "role" field to see what kind of person they are. But I wouldn't.
You may still need a "role" field in the join tables, say for the Events|Staff, who may have different roles per person, even different roles on different events.
As you see, there's two ways to do this. But if their operations really are separate, and unless there's a reason not to, I'd split 'em.