Is this even possible?
In Spring environment with bean function calls it works well enough. You can switch any particular component for mock for unit testing.
Is there a reasonable solution to this dilemma?
Camel/Mule integration and countless lines of code/params in your scripts for every piece of rest call? I don't think it's reasonable, but it's doable. Also, you can make simple helpers that call arbitrary rest service, in this case mock unit testing looks easier.
Is it a reasonable requirement
More or less it's part of business logic, but if you get requirement that something should not happen, then ask back what should process do in this case. Most restrictions like this in ruins clear business logic if they are left outside of process - most obvious outcome would be stuck process, because user is already selected, but he/she can't move process forward. You have to have plan B for every case, and it will make processes look like x-mas tree…
We're trying to think of a reasonable way to notify the workflow that it needs to update the task's candidate user list.
You can make signal/message catching events or receive tasks in parallel execution to handle this situation.
But why bother to notify workflow? In general case process is stored in DB waiting for user task/timer/event. You can simply update task properties outside of process - engine doesn't require you to be inside process to make changes.