A larger output length makes it stronger, up to a certain point which is already reached, by a large margin, when you have a 128-bit output. Enlarging it any further does not change security.
Details: barring any structural weakness, the security of a hash function depends on its resistance to generic attacks (aka "luck": attacker tries random inputs until a match is found), and that resistance depends on the hash output size. For a hash function with an output of n bits, it takes effort 2n for the attacker to find a preimage (i.e. some password, not necessarily the "real" one, which matches the output). Efforts beyond about 280 are too far away into the technologically infeasible to be envisioned by an attacker. At 128 bits, you already have a 248 margin, i.e. a factor of almost 300 thousands of billions over that which was already overly expensive. It would be like boasting about reimbursing the US national debt while not having more than 0.01$ in cash.
Larger output size also help against collisions; there again, the generic luck-based attacks have cost 2n/2 (and there you see why SHA-1 has a 160-bit output: to make the collision cost of 280 unreachable). However, collisions are not an issue for password hashing. The ability to compute collisions does not give any advantage to the attacker. It so happens that collisions are also infeasible with usual hash functions, but if they were feasible it would not be that much a problem.
The real weakness in password hashing is not the hashing; it is the password. Or, more accurately, the human mind behind the password. Successful attacks on hashed password are attacks which try potential passwords, not attacks which work on the hash function structural weaknesses, if any. Mitigations include slow hashing and salting, which is what PBKDF2 does.
You can store only 80 bits or so of PBKDF2 output (and the salt); things will still be safe. (For purely aesthetic reasons, make it 128 bits: these computer people, they just love powers of two.)