GRANT EXECUTE ON SomeProc TO SomeRole AS dbo
From BOL:



  Use the AS principal clause to indicate that the principal recorded as
  the grantor of the permission should be a principal other than the
  person executing the statement. For example, presume that user Mary is
  principal_id 12 and user Raul is principal 15. Mary executes GRANT
  SELECT ON OBJECT::X TO Steven WITH GRANT OPTION AS Raul; Now the
  sys.database_permissions table will indicate that the
  grantor_prinicpal_id was 15 (Raul) even though the statement was
  actually executed by user 13 (Mary).


https://docs.microsoft.com/en-us/sql/t-sql/statements/grant-transact-sql

So in this case the engine is recording the grantor as dbo, rather than the account running the actual code. 


I'm unsure why this would be - perhaps due to some aspect of the schema compare, dbo is used to ensure there are no orphaned records in terms of the grantor? Perhaps someone else can shed some light.
It should do this anyway - do you mean in this case the caller is the ExecSP role or the user themselves? Either way this should already be happening, if you've assigned the role or not.