unit testing for an application server
"My question is: Is this a correct approach?"
It's what you chose.  You made a lot of excuses, so I'm assuming that your pretty well fixed on this course.  It's not the best, but you've already listed all your reasons for doing it (and then asked follow-up questions on this specific course of action).  "correct" doesn't enter into it anymore, so there's no answer to this question.
"what kind of tests are covered with this approach?"
They call it "black-box" testing.  The application server is a black box that has a few inputs and outputs, and you can't test any of it's internals.  It's considered one acceptable form of testing because it tests the bottom-line external interfaces for acceptable behavior.
If you have problems, it turns out to be useless for doing diagnostic work.  You'll find that you need to also to white-box testing on the internal structures.  
"not being able to access the database layer in order to build/rebuild the schema," 
Why not?  This is Python.  Write a separate tool that imports that layer and does database builds.
"when will the test client going to connect to the server: per each unit test or before running the test suite?"
Depends on the intent of the test.  Depends on your use cases.  What happens in the "real world" with your actual intended clients?
You'll want to test client-like behavior, making connections the way clients make connections.
Also, you'll want to test abnormal behavior, like clients dropping connections or doing things out of order, or unconnected.
I wrote an application server (using python & twisted) and I want to start writing some tests. But I do not want to use Twisted's Trial due to time constraints and not having time to play with it now. So here is what I have in mind: write a small test client that connects to the app server and makes the necessary requests (the communication protocol is some in-house XML), store in a static way the received XML and then write some tests on those static data using unitest.
My question is: Is this a correct approach and if yes, what kind of tests are covered with this approach?
Also, using this method has several disadvantages, like: not being able to access the database layer in order to build/rebuild the schema, when will the test client going to connect to the server: per each unit test or before running the test suite?