I had to re-read the docs several times before I finally got what was going on here (more or less).
As far as I can tell, it works like this:

Gradle dependencies are grouped into "dependency configurations".
Gradle tasks are linked to these "dependency configurations".

Many of these dependency configurations have the same name as the task they're typically linked to,
but because a dependency configuration can be linked to multiple tasks, this isn't always the case.

By default, Gradle gives you the following set of "dependency configurations":

• default
• libs
• compile
• runtime
• testRuntime
• testCompile
• dists
• master

For example, the 'compile' configuration comes already linked to the 'compile' task,
and the 'testRuntime' configuration is linked to the 'test' task. Internally, Gradle
links configurations with tasks via the 'linkConfWithTask' API. You can use this
API within a build.gradle file by hand if you want to (thought it's seldom necessary):

dependencies
{
     linkConfWithTask( yourConfigName,   yourTaskName)
}

Some of the pre-built dependency configurations provided by the Java (or Groovy)
plugin are actually extensions of others. For example, the 'testRuntime' configuration
extends both the 'runtime' and 'testCompile' configurations.

How Gradle 0.5 links tasks with configurations is ugly and unintuitive. In my working copy there is now a much nicer and more powerful mechanism (as discussed on the mailing list recently). I hope to submit this within the next days.