While what laser says is true, I believe the reason for the SRID appearing as 0 is due to a decision made by Postgis developers that an undefined SRID should be reported as 0 -- there was a debate, in which -1 was also suggested. (I know this because I took part in said debate on IRC, and favoured -1, as it think it is more obviously undefined than 0).
If you look at the definition of the geography_columns view,
SELECT current_database() AS f_table_catalog,
n.nspname AS f_table_schema,
c.relname AS f_table_name,
a.attname AS f_geography_column,
postgis_typmod_dims(a.atttypmod) AS coord_dimension,
postgis_typmod_srid(a.atttypmod) AS srid,
postgis_typmod_type(a.atttypmod) AS type
FROM pg_class c,
WHERE t.typname = 'geography'::name AND a.attisdropped = false AND a.atttypid = t.oid AND a.attrelid = c.oid AND c.relnamespace = n.oid AND NOT pg_is_other_temp_schema(c.relnamespace) AND has_table_privilege(c.oid, 'SELECT'::text);
you will see a refence to a function postgis_typmod_srid. Following that rabbit hole, you will find the function defined here as:
#define TYPMOD_SET_SRID(typmod, srid) ((typmod) = (((typmod) & 0xE00000FF) | ((srid & 0x001FFFFF)<<8))).
It is easy enough to confirm this by creating a geography column and then looking at geography_columns. Given that you could also create a geometry column with any custom spheroid, it seems a bit pointless to allow this functionality in the geography type, given the prevalence of WGS84.