When linking against a dylib, the linker use the library install path that is encoded in the library itself, and has nothing to do with the actual library path.
You can query it using the otool command line tool:
otool -L /usr/local/lib/libc++.dylib
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 28.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
/usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version 14.0.0)
The first line is the install name (it can also be query by listing the load command using the '-lv' flag and looking for the LC_ID_DYLIB command).
Other lines are the library dependencies.
Using the same tool, you can check what library your binary will use.
If you want that your resulting binary use the library in /usr/local, you have to update your library first to change its install name, and then relink your binary.
It can be done using install_name_tool :
install_name_tool -id /usr/local/lib/libc++.1.dylib /usr/local/lib/libc++.1.dylib
The first '/usr/local/lib/libc++.1.dylib' is the install path that will be saved in the binary, and the second one, is the path to the binary itself.
Note that this tool may also be used to edit the path of a dependency in an existing binary. If you have an executable that link on /usr/lib/libc++.dylib, you can edit it to use your custom build instead using the '-change' flag.
About using new headers and linking against the system library. Don't forget that libc++ is a template library. Most of the code is in the headers, and only some implementation details are in the binary.
The binary interface of the library (exported functions) didn't change since the Lion release, so it is perfectly valid to use the new headers and link on the existing library. It may contains some bugs fixed in the 3.1release, but AFAIK, most of the changes between the Lion release and the clang 3.1 release was done in the headers.