Yeah. Then I mean the system-privilege, that might be missing. 
The perils of not having the system in front of me to check the names of the privileges. ^^
The account-privilege of the repository must be assigned to create an account there and to get the provisioning working for that user to that system, that is correct.
But your problem here is, that the account alreay exists, but IDM is still trying to create the user again and therefor fails, because it already exists. The modify-task is the one, that should be triggered, as you found out nicely.
So the reason it's not triggering is, that in the first check in IDM (where it goes either to "create" or to "modify" something is missing, that shoves the entry to modify. And my guess is, that the second repository-privilege is missing. The one, that you can't see in the UI, but only in the database. IDM should assign this privilege itself, when you assign the other one. So it's not something you control directly, normally.
I wish I had my system now, because I had created an SQL-query for this like one or two weeks ago, because I had the same issue as you have. Only in reverse. The privilege in question was still there and so instead of going to "create" my workflow went to "modify" for some users.
I don't remember the name of the view you have to check right now. GNAR! Was it one of the ext-views?
