Understanding time delay estimation for GPS?
For GPS, (simplifying for now by omitting corrections for ionsphere and orbit position and relativistic clock offsets), we determine the "Pseudo-range" to each satellite (SV), which will be the relative delay between all the received satellites we have correlated to relative to our local clock- using correlation as you described (delay each locally generated SV until you get a maximum peak and that delay value is your pseudo-range. Thus, as long as we have a pseudorange for at least 4 satellites, we can solve a matrix involving 4 equations with 4 unknowns: x position, y position, z position and time (which is the time error between our local clock and the clock of the satellite). The satellite's time keeping is highly accurate (using Atomic clocks) and the 4 equation solution allows us to use very inexpensive clocks in our local receivers. 

Below is shown a simplified 2D explanation showing how unique x,y position is determined on a plane with 3 satellites and perfect knowledge of time. Note how with 2 satellites there are two solutions. The same thing occurs with 4 satellites and unknown time, it is just that one of the solutions is on earth and the other can be neglected as it would be out in outer space.  In practice we benefit in a lower error solution by averaging over all satellites in view (forming a least mean square solution to an over determined set of equations).



Below is a sample output of what the output of a sliding correlator looks like for a particular SV in an actual captured GPS signal (the signal itself is indistinguishable from noise since the GPS signal prior to correlation is approximately 20 dB below the noise floor). Here we see the result of the spreading code that repeats every 1 ms, and the specific location of the peak in time relative to any local time reference we choose is the "pseudo-range".  These peaks are what you would get out of the Xcorr command (shown is the absolute value) and the horizontal axis where a peak occurs is the delay you are interested in finding. What is important is that all you need is the relative delay between all the satellites in view and your local clock reference (so you can pick any reference point you want as long as all codes are done with the same clock).  What I have seen in implementation, and perhaps this would be more complicated than you need, is to have a code NCO in a code tracking loop that is used to generate the codes for each satellite, and the code tracking is done using three correlators for each SV in an early-prompt-late arrangement each offset by 1/2 a chip. Early minus Late correlator output would then be proportional to code error (once acquired) and drives the Code NCO to track the delay. In such a fashion the code generator is always kept in alignment with the received code (in contrast to the sliding correlator approach I show below), and the relative delay is determined by the relative position of each code.



Below is the received signal prior to correlation (for the same signal used to generate the correlation plot above), with the blue representing the captured waveform after I had down-converted it to baseband and aligned it with the spreading code shown in red (as evidenced by the correlation peak). To note that any resemblance to the code that you think you might be able to see in the blue waveform to the red waveform is purely coincidental. The blue waveform in this view at this scale is visually indistinguishable from the AWGN process that is dominating it.



This is how the transmitted signal looks at that satellite (just two states +1 and -1):



And this is how that same signal looks as captured at our receiver, after down converting to baseband, removing all carrier and code offsets, and sampling at the mid point of each symbol (to match what we know was +1/-1 at the satellite). This matches very well to an AWGN noise process within the sampling space described, with no evidence of the signal without performing the correlation with the known sequence. 



To add to the simplified descriptions above, here is a link to a good reference on the complete PVT solution (position, velocity and time) using GPS: http://www.nbmg.unr.edu/staff/pdfs/Blewitt%20Basics%20of%20gps.pdf