Contrasting all the nay-sayers, let's assume real business need.
(for example, deliverable is source code, customers are from same line of business and therefore competitors to each other, and you business model promises to keep their secrets secret)
Furthermore, let's assume that your company has the tools to maintain all the branches, that is either manpower (let's say 100 developers dedicated to merging, assuming 5-day release delay; or 10 devs assuming 50-day release lag is OK), or such awesome automated testing that automated merges are truly tested both to core spec and extension spec in every branch, and thus only changes that don't merge "cleanly" require human intervention. If your customers pay not only for customisations but for maintenance thereof, this may be a valid business model.
My (and nay-sayers) question, is, do you have a dedicated person responsible for delivery to each customer? If you are, say, a 10,000-person company, it may be the case.
This could be handled by plugin architecture in some cases, let's say your core is trunk, plugins could be held in trunk or branches, and configuration for each customer is either a uniquely named file or is held in customer branch.
Plugins could be loaded at run time, or built in at compile time.
Truly many projects are done like this, fundamentally same problem still applies -- simple core changes are trivial to integrate, conflict changes must be either rolled back, or changes are needed to many plugins.
There are cases when plugins are not good enough, that's when so many internals of the core must be tweaked that plugin interface count becomes too large to handle.
Ideally this would be handled by aspect-oriented programming, where trunk is core code, and branches are aspects (that is extra code and instructions how to connect extras to core)
A simple example, you can specify that custom
foo is ran before or after core
klass.foo or that it replaces it, or that wraps it and can change input or output.
There's a ton of libraries for that, however the problem of merge conflicts does not go away -- clean merges are handled by AOP and conflicts still need human intervention.
Finally such business truly has to concern itself with branch maintenance, namely, is customer-specific feature X so common that it's cheaper to move it to core, even though not all customers are paying for it?