To answer your original question, yes the Web Services connector is architected to do exactly what you are asking by defining two Account Aggregation HTTP operations, with the second operation pointing back to the first operation by defining it as a parent endpoint.
The attribute name you use in the $response.attributeName$ keyword should actually be the raw attribute name that you receive back directly in the JSON response from the first call.
For example, in your response mapping of the first call, if you mapped a JSON attribute called userId to a schema attribute called USERID, you should be using userId, not the schema attribute name that you mapped. You also need to make sure that you are indeed mapping that userID back correctly from the first call. If the response mapping from the first call is not working correctly, then that may be another reason it’s not populated for the second call. When you run your aggregation, do you actually get accounts back with the userID attribute populated?
To troubleshoot you’d have to turn on log4j debugging on the VA for the Web Services connector, but the logs can sometimes be tough to capture if I am being honest.