Its constructor takes a POINT and a SRID. Since POINT is two doubles (8 bytes each), SRID is an integer (4 bytes), can one assume that the full structure takes 8*2+4=20 bytes of storage space?
Have a look at ST_MemSize. This gives you the size of toast tables, as well, so is more suitable than pg_total_relation_size and other built in Postgres functions, which do not -- although this only applies to larger geometries. Returning to your question, for a point,
SELECT ST_MemSize(ST_MakePoint(0, 0));
returns 32 bytes, which is 4 doubles (rather than the 2 you would expect). The reason for this is that there is additional meta-data, such as the endianness to store.
Add in the SRID, with,
SELECT ST_MemSize(ST_SetSRID(ST_MakePoint(0, 0), 4326));
returns 32 bytes.
Now, a Linestring, with two points,
SELECT ST_MemSize(ST_SetSRID(ST_GeomFromText('LINESTRING(0 0, 1 1)'), 4326));
returns 48 bytes, which is now only 16 bytes, that is 2 doubles, larger than the Point, as you would expect.
Now, if you buffer this point,
SELECT ST_MemSize(ST_SetSRID(ST_Buffer(ST_MakePoint(0, 0), 10), 4326));
you get 568 bytes, which due to the fact that there are 8 points by default per quarter circle segment, plus a repeated start point at the end, which you can check with,
SELECT ST_NPoints(ST_SetSRID(ST_Buffer(ST_MakePoint(0, 0), 10), 4326));
gives you 33*16 = 528, with the other 40 bytes coming from the SRID, endianness, etc.