It is not possible to double security level of Ed25519 any trivial way. Instead, doubling security level requires using another curve that is approximately 512 bit curve.
In systems compliant with RFC 7748, i.e. some of IETF specifications, there is Curve448 curve (Ed448-goldilocks). It is almost twice as strong as Curve25519 (its strength is 224 bits). This is often convenient alternative, because it is already available on some of the systems.
Widely deployed alternatives that are 256-bit security: Of course there are also BrainpoolP512 and NIST P-521 curves, which in theory provide 256 bit security. However, BrainpoolP512 and NIST P-521 are not considered to be as good as Ed25519 in all aspects possible (see e.g. https://safecurves.cr.yp.to/).
M-511 and E-521 are curves similar to Curve25519, which offer around 256-bit security level. However, because it is wide spread to consider security level 128 - 192 sufficiently strong for now, so larger curves are not used often in practice. For instance, NSA suite B site suggests that they consider 192-bit security level (i.e. 384-bit elliptic curves) to be sufficient to protect TOP SECRET materials.
Any optimized curve specific implementation of elliptic curves, such as the implementation of Curve25519 in lib sodium/NaCL is hard to replace efficiently with curve of different size. However, the API level of lib sodium/NaCL allows easy replacement of cryptographic primitives. Therefore, the "right" way to "hack libsodium/NACL" would probably be to provide the necessary curve(s) implementation(s) in API that is compatible with NaCL API. This usually requires use of different implementation rather than tweak of code implementing Curve25519. And some API work to adapt the API, as most Elliptic Curve implementations have APIs somewhat different from API in libsodium/NaCL.