I have a similar situation where I have numbers that animate on and off for a number puzzle game. I have a grid sprite sheet with each of these cells evenly spaced. I give each of these cells a number from 0 to X. From a cell number you can get a row and column like this:
row = cellNumber / cellsWide;
col = cellNumber % cellsWide;
Then I have an XML file that contains the cell numbers for each animation and other information about the sprite sheet. Like the width of a cell in pixels and the total width of the sheet. I load this info from the XML and store it in arrays for each animation.
The instead of using the built in sprite type in Unity, I build the sprite as a mesh that I create in code. Then all I have to do is alter the UV for this mesh to animate what cell is showing on the "sprite".
Actually in my case, I build all the sprites that are on the screen at any given time in a single mesh. This is a much more efficient way of rendering because all the sprites are rendered in a single draw call. Sort of like particles. That also means that my transform for the mesh is 0,0,0. I place each quad where it needs to go on screen.
The UV is calculated from the row and column, the width of the sprite cell, and the total width of the sprite sheet. The way I do it is to use one class to read the XML and create a copy of the unscaled, un-transformed quad. Then another class to get those quads and scale and move them to where they go as I make the full mesh. Then update that mesh each frame if things are moving.
So YES, it is completely possible and practice to create and populate sprite-TYPE animations using a script. But you have to decide which is more work. For me, I have the code down for creating meshes, reading in from XML, etc. And I have other needs that shy me away from the built in sprite system in Unity.
Alternatively you can just create sprite arrays and manually stick in each of the animation cells in there and access those programatically. But sound like that is what you are wanting to avoid.
With my above system you'll still have some manual inputting of animation cells, but it's sticking them in an XML document. Not sure which one will take less time.
There are a few options for replacements to the sprite system in Unity. There is one called Sprite Manager which is free and open source: https://github.com/Dkendal/SpriteManager.
There is also Sprite Manager 2 which is $150: http://www.anbsoft.com/middleware/sm2/
Or you can easily write you own like I'm doing.