The main reason you use a texture atlas is not because you want to reduce the amount of lines of code to define or use multiple small textures. If you have a lot of textures, all that information will likely be in a data file, or automatically generated code anyways.
We use texture atlases because when you're drawing stuff on the screen, it is much faster to draw a lot of sprites with one draw call, where each sprite takes from a different area of a large atlas, than to draw each sprite with a different texture, and therefore a different draw call. The trade in simplicity vs performance is generally acceptable, so atlasing textures, especially for GUI elements is a very common operation nowadays (don't forget to turn mipmapping off).
With audio, this doesn't really apply. Audio mixing is performed in regular (not GPU) memory, so it doesn't really matter if multiple audio clips are separate, or in a single large audio "atlas". Furthermore, it can add a bit of complexity, since there is an additional seek operation for every clip that you want to play.
If you want to do an audio atlas, go ahead. It will most likely not affect performance, but if you find that it makes managing your audio files easier, then it might be a good idea for your use case.
As to how to go about making an audio atlas, I'm not aware of many tools that do this for you, but I think it should be relatively easy to hack a quick tool, for example in C#, with NAudio to read, write and manipulate audio files. You can add padding between the audio files if you think that is necessary, and output your data in Json, or whatever file format you want.