There is nothing more secure than "secure". An attacker who can break it upfront, because it has "only" 128-bit security, is an attacker who has way more available computing power than all computers on Earth taken together (even including smartphones and coffee machines). It is implausible that such an attacker would swoop down so low as to bother breaking your key; he already knows all your thoughts, directs all your actions, and probably owns your soul as well.
Security levels beyond 128 bits are not meant to provide "more security", but to appease auditors, managers, customers and prospective mates (not necessarily in that order) by a powerful display of extra bits. This is like birds of paradise: by using an oversized key, you send the signal that you are so great that you can afford wasting CPU and network bandwidth on ridiculously enlarged cryptography.
Realistically, if (when) your key is broken, then it won't be through its size; it will be through software bug, hardware leak, or key misuse in a poorly designed protocol. In that sense, we can talk about actual security:
The designer of Curve25519 and author of its usual implementation is Daniel J. Bernstein, who is known to "know his trade". His code probably contains far fewer bugs than what most developers would do. Using his code is, all other things being equal, a good idea.
On the other hand, protocols are an important issue, and it is much easier to botch a protocol than a cryptographic algorithm implementation. By looking for a curve, you are looking for the wrong thing. You should think "what protocol should I use ?" and then (only then) worry about the specific curve, in case the protocol you chose happens to allow use of several curves. Curve25519 has not (yet) percolated into all or even most well-established protocols. For instance, there is no support for Curve25519 in SSL/TLS (there is one in SSH, though).