In the line "SET @sqlquery", try casting your @intID to an NVARCHAR(255).
EDIT - re-read your post and I see you tried this already. Is it giving the same error when you do the convert? What about if you cast instead of convert?
EDIT2 - I just tried this which does basically what you are doing, but doesn't actually execute the dynamic SQL:
DECLARE @strTableName NVARCHAR(255) = 'TEST1',@strFieldName NVARCHAR(255)='TEST2', @strStringToEncrypt NVARCHAR(255)='TEST3', @intID INT=10
DECLARE @SQLQuery AS NVARCHAR(500)
SET @SQLQuery = N'UPDATE dbo.AAA_' + @strTableName + ' SET [' + @strFieldName + '] = EncryptByKey(Key_GUID(''EncryptPIIKEY''), ''' + @strStringToEncrypt + ''') Where [ID] = ' + CONVERT(NVARCHAR(255),@intID)
and it returns exactly what I am expecting.
Why I would spend a bit more time on building up a proper fix:
Now, I do agree 110% about the SQL injection comments that Erland mentioned. For example, lets say somebody figures out the SQL query that is being run when they call the stored procedure. Knowing that, it would be pretty easy to manipulate it to do whatever you wanted. For example, lets assume there is no syntax errors (column names, table names, etc); this could be a value in @strTableName and all the other input variables were "0" (zero):
Table1 SET col1=col1; DROP DATABASE testDB; --
So your dynamic SQL would be:
UPDATE dbo.AAA_Table1 SET col1=col1; DROP DATABASE testDB; -- SET  = EncryptByKey(Key_GUID(EncryptPIIKEY),'0') WHERE [ID] = 0
Reading that, it would update all rows in table AAA_Table1 with the same value (so you should have no errors from that), then drop the database. Everything else would be a comment.
I do agree that the encryption COULD be done client side, but since you say "VBA" it makes me think this is something embedded in an office document (Excel?). And in that case, I would prefer to encrypt on the database side. I would do some sort of validation on all input strings though either on the database side OR the application side. The problem with doing the data validation is that you may not think of every possible case where things could go sideways. For example, if you fail the SP on a space being found in any parameter, they just do commands without space or with newlines in there or tabs... there is almost always a way around it when you do dynamic SQL.
Fixing the syntax error is not hard as it is just the way SQL does the data type conversions. If there is an INT in the value, it tries to convert the whole thing to int. For example:
DECLARE @int INT = 10
DECLARE @char CHAR(2) = '10'
SELECT @int, @char
Will succeed, but it will be implicitly converting @char to the data type int. You can verify this by changing the value of @char to be '1A' and you will get the error about converting the VARCHAR value '1A' to data type int. Now, why SQL thinks it is a VARCHAR when it is clearly a CHAR, I am not certain, but is also outside the scope of your question.