I've typically managed all kinds of project secrets via configuration files (often environment-specific) and then never commit these to source control. The format of these files can be whatever you want / whatever works well: xml, yaml, json, etc. Then the code is responsible for reading the values out of the config file.
Sometimes it is annoying that these values aren't in source control (makes deployment a little more difficult, for example), but it sounds like you are managing the values separately anyway, so that shouldn't add much overhead.
I'm not very familiar with Heroku, so I just answered the question generally. But after looking into it more, I can see where this could be a pain to manage.
It sounds like you already manage the config vars via the
bash_profile -- that's good because you'll want to have a "source of record" document where you can look at and change these values.
Beyond that, it sounds like naming is going to be the next most important thing. HEROKU_ADD_ON_1 isn't very descriptive. But DROPBOX_API_KEY or AWS_S3_BUCKET_KEY give a better idea of what the variable is. And you can distinguish between keys from the same provider through good naming too: FEATURE_A_AWS_KEY vs FEATURE_B_AWS_KEY.