As I said, I analyzed the code and found the following code in org.openqa.selenium.firefox.internal.NewProfileExtensionConnection:

public void start() throws IOException {
    int port = 0;

    lock.lock(connectTimeout);
    try {
      port = determineNextFreePort(DEFAULT_PORT);
      profile.setPreference(PORT_PREFERENCE, port);
      ...
    }
    ...
}

This means that the port is always overridden with the default port (whose variable
is marked as final).
I tested a small fix which is as simple as that:

public void start() throws IOException {
    int port = 0;

    lock.lock(connectTimeout);
    try {
      port = determineNextFreePort(profile.getPreference(PORT_PREFERENCE,DEFAULT_PORT));
      profile.setPreference(PORT_PREFERENCE, port);
      ...
    }
    ...
}

So we use the default port only when no other port has been specified in the profile.
Note that FirefoxProfile.getPreference(String key, String default) does not exist at
the moment and has to be implemented too.

It would be really great, if this fix could be part of a future Selenium release. I
really don't want to use a custom jar of selenium-server here.

To complete the implementation some more fixing is required:

org.openqa.selenium.firefox.FirefoxDriver:

protected ExtensionConnection connectTo(FirefoxBinary binary, FirefoxProfile profile,
      String host) {
    Lock lock = obtainLock(profile); // <-- added profile here
    ...
}

protected Lock obtainLock(FirefoxProfile profile) {
  return new SocketLock(profile.getPreference(FirefoxProfile.PORT_PREFERENCE,
    SocketLock.DEFAULT_PORT) - 1);
}

org.openqa.selenium.firefox.FirefoxProfile:

public int getPreference(String key, int defaultValue) {
    Object preference=additionalPrefs.getPreference(key);
    if(preference!=null && preference instanceof Integer){
        return (Integer)preference;
    }
    return defaultValue;
}

org.openqa.selenium.firefox.Preferences:

public Object getPreference(String key) {
    return allPrefs.get(key);
}

I built a new selenium-server-standalone.jar (based on version 2.29.0) with this fixes
and it works nice.

The only important thing to keep in mind when using custom port ranges, is, to take
care that they don't overlap (i.e. any start port - 1 must not be part of any other
used port range). So the minimum size of a port range is the maximum number of Firefox
instances which run simultaneously on a machine + 1. 
The only important thing to keep in mind is

Issue 5695 has been merged into this issue.

Issue 6859 has been merged into this issue.

Any idea when this fix is scheduled to be worked on? That will help me plan out my work
since I have a few issues that need this. Thanks.

I have issued a pull request via github to address this issue:
https://github.com/SeleniumHQ/selenium/pull/228

For those interested in pulling the commit into your own build, please cherry-pick
19269ba from

https://github.com/shutterfly/selenium/tree/issue-5172-set-port-for-FirefoxDriver-via-preferences

We have been running this change on our internal grids for approximately 2 months.
 Problems with "Unable to bind to locking port" went-away immediately after deploying
this change.

This issue was closed by revision 8204b46236a3.

This issue should be reopened, as it is again not working properly (I'll re-paste my
comment from github):

The "locking port" is now always 7054, even if you define custom webdriver_firefox_port.

If I understand the source correctly, the bug may be re-introduced with commit d6f093a6edd97cf0339aea38e6ac32a4fbbca640
("Fixing socketlock bug with reusing the same profile multiple times"), causing the
default constructor of org.openqa.selenium.internal.SocketLock being called:

    public SocketLock() {
        this(localhost);
    }

and `localhost` value is *always* port 7054. We are seeing the "Unable to bind to locking
port 7054 within 45000 ms" exceptions from the node, even if we explicitly define different
webdriver_firefox_port. This port is than used to communicate, but the locking port
is still 7054.

Caused by: org.openqa.selenium.WebDriverException: Unable to bind to locking port 7054
within 45000 ms
Build info: version: '2.44.0', revision: '76d78cf', time: '2014-10-23 20:02:37'
System info: host: 'omnb', ip: '10.1.11.155', os.name: 'Linux', os.arch: 'i386', os.version:
'3.17.2-1-custom', java.version: '1.7.0_71'
Driver info: driver.version: FirefoxDriver
        at org.openqa.selenium.internal.SocketLock.lock(SocketLock.java:98)
        at org.openqa.selenium.firefox.internal.NewProfileExtensionConnection.start(NewProfileExtensionConnection.java:84)
        at org.openqa.selenium.firefox.FirefoxDriver.startClient(FirefoxDriver.java:246)
        at org.openqa.selenium.remote.RemoteWebDriver.<init>(RemoteWebDriver.java:114)
        at org.openqa.selenium.firefox.FirefoxDriver.<init>(FirefoxDriver.java:193)
        at org.openqa.selenium.firefox.FirefoxDriver.<init>(FirefoxDriver.java:186)
        at org.openqa.selenium.firefox.FirefoxDriver.<init>(FirefoxDriver.java:104)
        ... 14 more

This bug now effectively prevents us from using multiple parallel Firefox instances
on our Jenkins CI server, and there doesn't seem to be any workaround...

This absolutely the situation that we're in; I'm unable to figure out why the ability
to circumvent the lock was restored. @barancev is it possible for you to point towards
the symptoms that occur/the issue that the lock is there to resolve?