Full name as a Primary Key (PK) is my preferred choice; is there another way?
You are absolutely right that a surrogate key (ID or otherwise) won't solve your root problem which is more fundamental than the database schema - "How do you tell speakers apart in the real world?"
That's a business question, and full name may or may not be good enough. 
You should ask yourself - If I have 2 speakers named John Doe, how do I tell them apart in the real world, and that will be your answer to the key.

Common attributes used to identify people in these kind of data universes are Email address, User name / Alias (login to your system), SSN, perhaps even name + address may be unique enough for your business needs - what are the odds of 2 people with the exact same name residing at the same address? 
Theoretically, you should accommodate every possible case, but in practice this would be much better than having a surrogate key, which will guarantee duplicates as you correctly observed, and not having any way to tell the entities in the database apart.
Using an ID will lead to much worse data consistency problems later on when the 2 John Doe start showing up in the wrong conferences :-)

HTH