The smoothing of the scrolling algorithm is very simple as far as I can tell. Let's say you have two positions A (X = 0) and B (X = 360). To smoothly move from position A to position B, start at position A and then add a fraction of the difference between A and B. The number you divide by determines the speed of the scroll. It provides a nice smooth scrolling effect without the need for any fancy calculations. Something like:
Scroll.X = A.X + (B.X - A.X)/30 (experiment with that number 30, the higher it is, the slower the scroll). In this example, on the first frame, Scroll.X will be 0. On the last frame of this algorithm, it will be 360. The only thing that changes based on the '30' is the speed at which the scroll takes place. The starting and ending points will remain the same (which is one of the things Mulkaccino was talking about when he mentioned stick-to points). So this (the 30) is the number that should be tweaked based on the flick velocity. We can call this number the 'smoothing ratio'.
To determine the smoothing ratio (which is what I'm calling the number to divide by i.e 30 in the example), take the flick velocity into account. Whenever they let go, get the difference between the initial touch point X and the release point X and divide by the time it took for them to perform this action (which will get you the velocity = distance/time). So you'll need to record the time the initial touch occurs, and then find the difference when they release, and then calculate your speed. The greater the speed, the lower your smoothing ratio should be, creating a faster scroll.
A simple way to determine the smoothing ratio might be something like 30/speed. So now when you have really high speeds, you'll get a really low smoothing ratio. Experiment with numbers until you get something that looks natural based on the velocity of the flick. I chose 30 randomly. The best part about this technique is that no matter the speed of the flick, it will always scroll to the same position, and smoothly too. All the flick will determine is how fast this scroll will take place.
Alternatively, you could do what Mulkaccino was talking about, which is a great way to do it that offers the user control over HOW much they scroll based on velocity. Calculate the velocity using what I said above and then apply that velocity to the scroll as follows:
Scroll.X = Scroll.X + Velocity * dt.
Every frame, keep decreasing the Velocity (by a multiple of dt I guess) until it equals zero.
The only problem with my version of this approach is that you won't have a defined end point for the scroll. They could potentially flick too fast, causing the scroll to go on for way longer than expected. You could limit the speed of the scroll, but then it may feel unnatural because the speed did not initially correspond to the flick. Mulkaccino may be able to offer more insight in this area.