I'm assuming your using Allegro 5. If that is the case, your best bet if you want to draw many sprites is to use atlasing and al_hold_bitmap_drawing(). Shaving a few pixels from a texture won't make any difference. The biggest cost when rendering many different sprites comes from texture binding. If your put all your graphics onto an atlas you can draw many different sprites with only one texture binding. Your drawing code something look something like this:

al_hold_bitmap_drawing(true);
for(i = 0; i < total_sprites; i++)
{
    al_draw_bitmap(sprite[i].bitmap[sprite[i].type], sprite[i].x, sprite[i].y, 0);
}
al_hold_bitmap_drawing(false);

Each bitmap will need to be a sub-bitmap of the atlas bitmap which contains all the sprite images. You can draw thousands of sprites this way with good performance, even on older hardware.

You can search the forums for discussions of atlasing. It has come up a few times. You might find this useful.

Ahh, I was confused because you were talking about the cost of pixel drawing vs. the cost of drawing more sprites.

I wouldn't worry about saving memory unless it is becoming a problem. If I was going to trim the extra space from around sprites I would make a structure to hold the extra positioning information and make a set of drawing functions to match. Something like this:

typedef struct
{

    ALLEGRO_BITMAP * bitmap;
    int ox, oy;

} MY_BITMAP;

void my_draw_bitmap(MY_BITMAP * bp, float x, float y, int flags)
{
    al_draw_bitmap(bp->bitmap, x + bp->ox, y + bp->oy, flags);
}
...

Premature optimization, maybe. Is this one of the optimizations you are considering after designing everything else? You are actually talking about splitting up an arbitrary image. I wouldn't go through the trouble, unless I had some serious need for the graphics memory And couldn't get it from anywhere else.
What kind of hardware are you running? Are you using a software renderer? How big are the sprites?
An ALLEGRO_BITMAP definitely has some memory overhead. So it might only pay off, if you use a small number of big sprite-sheets. In software you have the problem that your normal memory is your graphics memory. In hardware you have the problem that most textures must have power-of-two dimensions (and the textures will have additional dead-space to accommodate that).
Allegro 4 has RLE-sprites, which would be smaller. In Allegro 5 you could try turning on sub-samples and drawing the original sprite rotated. If the hardware you're working on supports it, you could even look into texture compression, I guess. If you're using software, RLE might be a good option.