Issues with module signing and SSIS catalog internal procedures
In Vedran's code which you reference, he also signs the stored procedure in the other database.  I do not see in your code that you have taken that final step.

Erland Sommarskog has an extensive discussion at http://www.sommarskog.se/grantperm.html of this problem.  This includes a discussion of, in his words, "the Problematic EXECUTE AS".

In the following link, which is for starting SQL Agent jobs, you can see yet another approach to delegating rights to a login which has no particular rights.  See: Allow non-sysadmin, non-owner of a SQL Server Agent job to execute it

If that appeals to you, you can create your own stored procedure to allow your user to start the SSIS process.

10/20/2014 Edit: "Cannot execute as the server principal because ..."

First of all, if you are a sysadmin, then the problem is not your rights, but the context you are trying to run.  (I believe that you are a sysadmin.)  So it could be something like:


If the server principle you want to use is a Windows Group it cannot be impersonated.
Have you recently restored a system database (e.g. msdb) from another server? Then the account you see in msdb may not match an account on the current server. (You might see the same name in database_principals, but the sid could be different.) If so, try using exec sp_change_users_login 'AutoFix','principalname'.
If the owner of a database (in master.sys.databases)is not the same sid as the 
database's dbo user, then it cannot be impersonated.  (This is unlikely in msdb since sa is the normal owner of msdb.)  
If the login was dropped, even if the user remains in the database, you may not be able to impersonate the account.


And there are likely other flavors as well.