I've implemented the sway algorithm, and visually it looks about right. I ended up encoding a sway force with the object's physical representation (each game object can be attached to a particle, with position, velocity, and now sway force information). The sway force dissipates over time, rather than being reset each frame (which would also work).
However getting a matching sound effect to work is a bit more difficult! At first I had it set up so that when you walk into the bush, it triggers a sound effect (as long as one isn't already playing). This is ok, but the sound stops playing when you leave the bush even though it continues to sway. This is an event-oriented approach, basically; when you walk into the bush, play the bush rustling sound effect. One can imagine a moderately complex algorithm to let the sway sound effect play on repeat (fading out as it does so) after you leave the bush, but it feels complex and weird.
The next idea I had, was to tie the sound effect to the renderable. This turns out to be right idea, sort of. The model I adopted for sound effects in Texas was the idea of "soundable"; an object has a renderable, something that is drawn to the screen, so why not also a soundable, something that is played into the sound engine?
The secret is to create a new soundable type, called "sway", which bases it's behaviour on the same data that the sway algorithm is based on. Imagine the sway algorithm as a pendulum that moves across an axis; every time it moves across the axis, we want to trigger the sound effect. If we use, in effect, the same algorithm (this time in just one dimension) and trigger the sound effect for each time the pendulum crosses the zero line, with the velocity relating to the amplitude of the sample, it should create a good effect; moreover, when we add wind (which will, essentially just apply a "windy" sway force vector to all objects) it should create a natural sound environment that is tied to the gameplay objects.
Now let's see if it works...