Just a note on evala.
In versions of Maple from 2016 and earlier your evala(ee) doesn't do anything whatsoever to ee.
If you do

op(3,eval(evala));

in Maple 2016 you get:
`Copyright (c) 1991 by the University of Waterloo. All rights reserved.`
If you do the same in Maple 2017.3 you get
lock, `Copyright (c) 2016 by Maplesoft. All rights reserved.`
and in Maple 2018:
`Copyright (c) 2016 by Maplesoft. All rights reserved.`

I did this many times:
 

restart;
a:=[seq(RootOf(_Z1^6-3*_Z1^2-2*_Z1+11, index = i), i = 1 .. 6)];
ee := a[1]*a[5]+a[2]*a[6]+a[3]*a[4];
evala(ee);

The first time I lost the kernel connection.
Several times I got the correct value 4.
One time I got the alarming error message:

Error, (in evala/Normal/preproc0) this should not happen

I have chosen interface(typesetting=standard) in Tools/Options/Display so don't get the problem with INTERVAL.
This works fine:

interface(typesetting=standard);
INTERVAL(1..2, 3..4);

but not if typesetting=extended is used.

I changed the order of alias and seq and repeated the following code including the restart 10 times in one worksheet.
Then executed the worksheet using !!! and doing it several times. I got the result 3.139680582-1.737673929*I each time except for the last digits which varied between 2, 3, and 4 for the real part and 27, 28, 29, 30 for the imaginary part.
 

restart;
alias(seq(a[i] = RootOf(_Z1^6-3*_Z1^2-2*_Z1+11, index = i), i = 1 .. 6));
ee := a[1]*a[5]+a[2]*a[6]+a[3]*a[4];
evalf(evala(ee));

I also tried inserting an evalf(ee) before the evalf(evala(ee)). That made it very likely that 4. was the result, but not consistently. The other result was as above.
 

restart;
alias(seq(a[i] = RootOf(_Z1^6-3*_Z1^2-2*_Z1+11, index = i), i = 1 .. 6));
ee := a[1]*a[5]+a[2]*a[6]+a[3]*a[4];
evalf(ee);
evalf(evala(ee));

I use the 64 bit version of Maple 2018.
## Addendum
The following also mostly return 4 but not consistently:
 

restart;
alias(seq(a[i] = RootOf(_Z^6-3*_Z^2-2*_Z+11, index = i), i = 1 .. 6));
ee := a[1]*a[5]+a[2]*a[6]+a[3]*a[4];
evala(a[1]); # has an effect apparently
evala(ee);

You cannot have infinity in your boundary conditions.
You may have a look at the building blocks for a possible series solution:
 

pdsolve(pde,build);

@Math Pi Euler Just do Z[3](0) if x = 0.
I added a comparison to the numerical solution as done in my other answer.

You are saying that B2211 is positive since B211 and B221 are.
The problem with that is that both B211 and B221 don't remain positive.
MaplePrimes18-03-24_odesys.mw

The plot of B211 and B221:

If your system doesn't behave the way you expect I'm pretty sure it has absolutely nothing to do with odeplot.
My guess is that the problem (if there is one) is in your own formulation of the problem sent to dsolve.
Just take a look at sol(3000) which produces

quite independent of odeplot. I'm also pretty confident that dsolve doesn't make blunders like that.

Nothing is attached.

@CK1992 What it means is that
 

exp(g(x,0)*sqrt(x)/(1+varepsilon*g(x,0)*sqrt(x)))
## is replaced by
1+g(x,0)*sqrt(x)/(1+varepsilon*g(x,0)*sqrt(x)

Starting from BC you can make the replacement like this:
 

BC2:=eval(BC,exp=(x->1+x));

so when varepsilon=0 you get
 

BC2 := {g(0, eta) = 0, g(x, 20) = 0, phi(0, eta) = 1, phi(x, 20) = 1, D[2](g)(x, 0) = -phi(x, 0)*(1+g(x, 0)*sqrt(x)), D[2](phi)(x, 0) = 0}

I did that in a desperate attempt to get some result. That replacement can only be expected to be any good if the argument to exp is small. The argument is g(x, 0)*sqrt(x)/(1+varepsilon*g(x, 0)*sqrt(x)) and that is only small if g(x, 0)*sqrt(x) is small.
So it doesn't look promising, does it?

@CK1992 In fact I tried using an eta value greater than zero. That worked better at least when using the approximation exp(x) = 1+x. Also I used spacestep=0.1.
Another thing: The boundary value for D(T) is given at eta=20, i.e. you have D(T)(20) = 0.
Could that (or should that) be chosen smaller, e.g. eta=10?
The reason I ask is that the plots

plots:-odeplot(sol1,[[eta,T(eta)],[eta,diff(T(eta),eta)]]);

show that T and T' has become basically constant already at eta=10.
Using that also, this produced a seemingly exponentially growing g*sqrt(x):
 

pds:-plot(g*sqrt(x), x = 0 ..3 , eta = .0001, color = red);

But remember, I was using exp(x) = 1+x, so no great news.

@CK1992 I left out the change in alpha from 1 to zero.
So now a "solution" is produced.
The input to pdsolve when different from the names of the dependent variables (as in this case) should probably include the independent vaiables as in: g(x,eta)*sqrt(x). 
Besides that I didn't have much success. I tried replacing exp by its first taylor polynomial, thus using exp(x) = 1 + x.
Only limited success. 

@CK1992 I tried with these conditions you just gave:
 

subBC1 := -phi(x, 0)*exp(g(x, 0)*sqrt(x)/(1+varepsilon*g(x, 0)*sqrt(x)));

subBC2 := alpha*phi(x, 0)*sqrt(x)*exp(g(x, 0)*sqrt(x)/(1+varepsilon*g(x, 0)*sqrt(x)))

BCtest := {g(0, eta) = 0, g(x, 20) = 0, phi(0, eta) = 1, phi(x, 20) = 1, (D[2](g))(x, 0) = subBC1, (D[2](phi))(x, 0) = subBC2}

From
 

pds := pdsolve(PDE1, BCtest, numeric, spacestep = .25);

I get the same error received before: too complex!
No wonder though, because your "new" conditions are exactly the same as the old!
Did you copy the wrong ones?

I have reason to believe that that problem is gone soon.

@Parham2016 Since dsolve uses solve for the job, you might as well be using solve.
One note: Remove the tilde after indets.

indets~(eval({E1, E2},B=10)); #returns {{C1,Nu}}
whereas

indets(eval({E1, E2},B=10)); # returns {C1, Nu}

solve wants the latter form. Apparently the double curlies don't bother dsolve.