Does a varchar field's declared size have any impact in PostgreSQL?

They are identical.

From the PostgreSQL documentation:

http://www.postgresql.org/docs/8.3/static/datatype-character.html

Tip: There are no performance differences between these three types, apart from increased storage size when using the blank-padded type, and a few extra cycles to check the length when storing into a length-constrained column. While character(n) has performance advantages in some other database systems, it has no such advantages in PostgreSQL. In most situations text or character varying should be used instead.

Here they are talking about the differences between char(n), varchar(n) and text (= varchar(1G)). The official story is that there is no difference between varchar(100) and text (very large varchar).

TEXT /is/ the same as VARCHAR without an explicit length, the text

"The storage requirement for a short string (up to 126 bytes) is 1 byte plus the actual string, which includes the space padding in the case of character. Longer strings have 4 bytes overhead instead of 1. Long strings are compressed by the system automatically, so the physical requirement on disk might be less. Very long values are also stored in background tables so that they do not interfere with rapid access to shorter column values. In any case, the longest possible character string that can be stored is about 1 GB."

refers to both VARCHAR and TEXT (since VARCHAR(n) is just a limited version of TEXT). Limiting your VARCHARS artificially has no real storage or performance benefits (the overhead is based on the actual length of the string, not the length of the underlying varchar), except possibly for comparisons against wildcards and regexes (but at the level where that starts to matter, you should probably be looking at something like PostgreSQL's full-text indexing support).

There is no difference between varchar(m) and varchar(n)..

http://archives.postgresql.org/pgsql-admin/2008-07/msg00073.php

There is a difference between varchar(n) and text though, varchar(n) has a built in constraint which must be checked and is actually a little slower.

http://archives.postgresql.org/pgsql-general/2009-04/msg00945.php